TOWARD  PROGRAM  ILLUSTRATION 

by 

Edward  Yarwood 

Technical  Report  CSRG-8U 
October,  1977 


COMPUTER  SYSTEMS  RESEARCH  GROUP 

UNIVERSITY  OF  TORONTO 


TOWARD  PROGRAM  ILLUSTRATION 


by 


Edward  Yarwood 


Technical  Report  CSRG-8U 
October,  1977 


The  Computer  Systems  Research  Group  (CSRG)  is  an  interdisciplinary 
group  formed  to  conduct  research  and  development  relevant  to  computer 
systems  and  their  applications.  It  is  jointly  administered  by  the 
Department  of  Electrical  Engineering  and  the  Department  of  Computer 
Science  of  the  University  of  Toronto,  and  is  supported  in  part  by 
the  National  Research  Council  of  Canada. 


Abstract 

This  thesis  describes  an  automatic  tool  for  visualization  of 
the  execution  of  computer  programs.  A  methodology  for  tracing 
the  execution  of  programs  is  developed  that  does  not  obscure  the 
correspondence  between  the  program  text  and  the  sequence  of 
statements  executed.  Graphical  conventions  are  described  for 
concisely  displaying  data,  in  terms  of  assertions  about  the  data 
where  possible.  An  experimental  system  incorporating  these 
conventions  has  been  developed  to  produce  illustrations  of  the 
execution  of  programs  in  a  subset  of  the  PL/I  language.  These 
illustrations  consist  of  program  text,  pictorial  "snapshots"  of 
the  program's  data,  and  explanatory  messages.  Examples  of 
illustrations  produced  by  the  system  are  presented.  Directions 
for  future  work  are  discussed. 
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Chapter  1 
I ntroduc  tion 

Pictures  can  be  useful  as  aids  to  understanding  computer 
programs,  or  any  other  complex  phenomena.  Yet  many  drawbacks  are 
associated  with  using  pictures  as  a  means  of  commun icat ion. 
Problems  of  the  ambiguity  or  unsuitability  of  pictures  can  often 
be  overcome  if  we  restrict  the  universe  of  discourse  of  our 
pictorial  information  and  adopt  simple  visual  conventions  to 
represent  the  phenomenon  being  pictured.  Problems  of  cost, 
reliability  and  consistency  can  be  overcome  by  automating  the 
production  of  the  pictures.  This  thesis  describes  a  system  to 
produce  illustrations  of  the  execution  of  programs  in  SP/k ,  a 
subset  of  PL/I.  These  illustrations  consist  of  program  text, 
pictorial  "snapshots’'  of  the  program's  data,  and  explanatory 
messages.  Although  these  illustrations  are  dependent  on  a 
specific  execution  of  the  program  on  specific  data,  the  system  is 
designed  to  allow  tlie  user  to  direct  the  system  to  generate  a 
small  number  of  illustrations  which,  taken  together,  give  a  good 
general  picture  of  what  the  program  is  intended  to  do.  This  tool 
can  be  thought  of  as  a  step  towards  easing  the  task  of 
communicating  with  and  about  computers,  using  the  technigues  of 
computer  graphics. 

Chapter  2  discusses  in  greater  detail  the  desirabilities  and 
dangers  of  using  pictures  to  describe  computer  programs.  Chapter 
3  introduces  some  definitions  and  presents  the  basic  rules  which 
govern  the  illustration  process  as  carried  out  by  the  system. 
Chapter  4  gives  a  short  example  of  the  use  of  the  system,  as  an 
informal  introduction.  Chapter  5  describes  in  detail  the 
operation  of  the  system  and  the  commands  used  to  specify  what  the 
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system  is  to  do.  Chapter  6  gives  an  example  of  the  operation  of 
the  system  on  a  moderately  complicated  program,  discussing  the 
commands  used  and  the  resulting  output.  Chapter  7  discusses  work 
by  others  on  programming  support  tools,  that  specifically  relates 
to  the  problem  of  visualizing  the  execution  of  programs.  Chapter 
8  discusses  some  possible  extensions  and  improvements  to  the 
illustration  system  as  it  is  currently  implemented.  Chapter  9 
discusses  different  approaches  to  the  problem  of  program 
visualization  that  are  beyond  the  scope  of  the  system  developed. 
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Chapter  2 
The  Problem 

In  writing  and  developing  a  program,  the  programmer  often 
finds  it  useful  to  express  himself  in  pictures,  both  to 
communicate  with  himself  and  with  others.  Pictures,  if 
thoughtfully  prepared,  can  present  information  much  more 
concisely  then  the  formal  or  natural  languages  available  to  the 
programmer.  Pictorial  representation  of  the  flow  of  control  of  a 
program  or  an  automated  process  has  evolved  into  flowcharting. 
Pictures  are  equally  useful  in  describing  data,  both  the 
structure  of  the  data  to  be  used  by  a  computation,  and  the 
contents,  or  state,  of  the  data  at  a  specific  point  in  the 
execution  of  §.  computation.  A  typical  vehicle  for  such  an 
instantaneous  description,  or  snapshot,  is  the  variable  dump.  A 
picture  can  be  an  improvement  on  a  variable  dump  not  only  by  its 
conciseness  but  by  giving  a  more  general  description  of  the  state 
attained  by  a  computation  at  a  point,  regardless  of  the  initial 
data  presented  -to  the  computation  or  the  number  of  times  such  a 
point  has  already  been  passed. 


In  practice,  pictures  are  often  used  by  programmers  in 
program  development  and  informal,  personal  communication.  All 
too  frequently,  this  valuable  pictorial  information  gets  no 
farther  than  scratch  paper  or  blackboard,  and  permanent 
descriptions  of  the  program  are  preserved  in  a  less  readable 
form.  Reasons  for  this  are. 


Conventions  for  pictorially  describing  data  are 


personal  and  informal 
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Snapshots  of  data  always,  to  some  extent,  describe 
examples  of  the  execution  of  a  program,  not  the  general 
case.  Sets  of  "relevant'1  examples  are  usually  large. 

Readable,  neat  copies  of  pictures  are  expensive  to 
produce  and  reproduce,  whereas  programs  and  natural  language 
descriptions  are  cheaply  stored,  manipulated  and  reproduced 
by  machine. 

With  manually  generated  pictures,  there  is  no  guarantee 
of  correspondence  with  a  real  computation  running  on  a  real 
machine. 


Flowcharting,  particularly 
into  wide  use  as  a  documentation 
of  standards  and  tools  to  overc 
snapshots  of  data  tend  to  appear 
manuals;  in  books  such  pictures 
form,  but  only  by  the  use  of 
techniques.  The  purpose  of  the 
this  thesis  is  to  provide  an  auto 
that  represent  the  state  of 
creation  process  is  driven  by  the 
resulting  output,  in  which  the 
the  text  of  the  program,  is 
generality  to  be  used  as  a  per 


automatic  flowcharting,  has  come 
tool  because  of  the  development 
ome  these  objections.  Pictorial 
in  programming  textbooks  and 
have  been  preserved  in  permanent 
expensive,  error-prone,  manual 
experimental  system  described  in 
mated  means  of  creating  pictures 
a  program's  data.  The  picture- 
execution  of  the  program.  The 
data  snapshots  are  combined  with 
of  sufficient  conciseness  and 
manent  form  of  documentation  and 


communication  about  the  program 
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Chapter  3 
An  approach 

3 . 1  Some  goals 


Work  on  automated  program  Verification  may  some  day  give  us 
tools  to  let  us  automatically  generate  useful  pictorial  images 
and  other  additions  to  program  text,  without  reference  to 
specific  executions  of  a  program.  In  the  meantime  we  have 
constructed  a  system  which  examines  and  explicates  the  specific 
execution  of  a  program  on  specific  data.  Although  examples  are 
far  from  ideal  for  describing  a  program,  when  carefully  chosen 
and  presented  they  can  improve  the  reader's  comprehension  of  a 
program.  Some  goals  of  this  system  are. 


Input  to  the  system  should  consist  of:  a  program 
well-known  language,  the  input  data  for  the  program, 
some  additional  commands  to  guide  the  system.  These 
must  not  be  too  complicated  or  reguire  too  much  work  on 
part  of  the  user.  Dse  of  the  system  should  not  iit 
significant  restrictions  on  the  programming  language 
originally  defined. 


in  a 
and 
last 
the 
pose 
as 


The  output  of  the  system  should  consist  of  program 
text,  neatly  formatted  and  automatically  paragraphed, 
augmented  by  explanatory  comments  and  pictures  describing 
the  state  of  the  program  and  its  data. 

These  pictures,  or  snapshots,  of  data,  which  the  system 
is  to  produce,  should  use  a  variety  of  graphical  conventions 
to  provide  better  conciseness  and  readability  than  an 
ordinary  variable  dump. 
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The  single  page  should  be  a  fundamental  unit  of  system 
output,  and  aids  for  relating  information  on  different  pages 
should  be  provided. 

In  particular,  we  want  the  output  of  the  system  to  consist 
of  program  text  interspersed  with  these  snapshots,  so  that  the 
snapshots  reflect  the  state  of  the  computation  at  the  point  the 
code  is  broken.  For  such  output  to  be  useful,  the  sequence  of 
text  and  snapshots  in  text  space  should  reflect  the  sequence  in 
time  of  states  of  the  computation.  By  imposing  suitable 
constraints,  we  can  ensure  this. 

3 . 2  Some  definitions  and  rules 

Given  a  program  in  SP/k,  which  has  the  same  control 

structures  as  PL/I  but  no  GO  TO,  we  define  a  flowgroup  as  that 

part  of  the  program  text  that  coincides  with  either  a  loop  or  a 

procedure.  Given  an  execution  of  such  a  program  on  specific 
data,  we  define  a  flowgroup-e  xecution  as  one  iteration  of  the 
associated  loop,  or  one  execution  of  the  associated  procedure,  of 
a  given  flowgroup.  Thus  a  flowgroup  is  a  subset  of  text  space 
and  a  flowgroup- execution  is  a  subset  of  execution  space.  For  a 
given  program  and  its  execution  on  some  data,  each  flowgroup  may 
give  rise  to  zero,  one,  or  more  flowgroup-e xecution s.  The 

flowgroup  provides  us  with  the  appropriate  building  block  for 
illustrating  the  execution  of  a  program,  since  execution  of 
statements  within  a  f lowgroup-execution  either  matches  the 
sequence  of  statements  in  text  space,  or  is  part  of  another, 
subsidiary,  flow group-execut ion.  Each  flowgroup-e xecution  of 
each  flowgroup  is  a  candidate  for  an  illustration  by  the 
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illustration  system.  Such  an  illustration  of  a  flowgroup- 
execution  will  have  the  following  characteristics. 

Program  text  outside  the  flowgroup  will  be  omitted  or 
visually  marked. 

If  the  flowgroup  is  a  procedure,  declarations  and 
subroutine  definitions  within  the  flowgroup  will  be  visually 
marked . 

Program  text  in  the  flowgroup  but  not  executed  in  the 
flowgroup-e xecution ,  because  of  conditional  branching  or 
execution  of  a  RETURN  statement,  will  be  visually  marked. 

Program  text  of  loops  encountered  during  the  flowgroup- 
execution  will  be  visually  marked  and  accompanied  by  a 
message  indicating  how  many  iterations  of  the  loop  occurred 
during  that  particular  f lowgroup-execut ion.  Each  of  these 
iterations  constitutes  a  separate  f lowgroup-exec ution . 

Remaining  text  in  the  flowgroup-e xecution  is 

interspersed  with  snapshots  at  appropriate  points,  including 
the  beginning  and  end  of  the  flowgroup.  This  remaining 
unmarked  text  consists  of  statements  executed  exactly  once 
during  the  f lowgroup-execution. 

Given  this  means  of  separating  the  program  into  flovgroup- 
executions,  we  need  a  coordinate  system  to  relate  these 
f lowgroup-executions  to  each  other.  With  each  procedure- 
f lowgroup-execution  we  associate  the  number  of  times  that 
procedure  has  been  called  (since  start  of  the  program) .  For  a 
loop- flowgroup-e xecution  we  want  to  be  able  to  group  iterations 
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within  a  single  entry  to  a  loop,  so  we  count  the  number  of  times 
the  loop  has  been  entered  (a  loop  tested  but  not  executed  is  not 
considered  entered) ,  and  the  number  of  iterations  of  that  loop 
since  entry.  An  illustration  produced  by  the  system  will  be 
identified  by  a  header  line  containing  the  name  of  the  flowgroup 
and  its  (entries)  or  (entries,  iterations)  coordinate.  When  a 
procedure  is  called  ■  as  part  of  a  f lowgroup-execution  that  is 
being  illustrated,  a  message  will  be  added  to  the  program  text 
giving  the  entry  number  of  the  execution  of  the  procedure.  This 
acts  as  a  pointer  to  the  illustration  of  that  procedure 
execution.  A  similar  message  is  appended  when  a  loop  is  executed 
in  a  flowgroup-e xecution. 

This  methodology  for  tracing  program  execution  can  easily  be 
extended  to  any  language  using  control  structures  similar  to 
those  of  the  SP/k  subset  of  PL/I.  It  can  be  extended  to  include 
the  treatment  of  other  control  primitives  such  as  an  EXIT  from  a 
loop  (or,  in  PL/I,  the  use  of  a  GO  TO  to  provide  such  an  exit). 
The  methodology  can  not  be  extended  cleanly  to  account  for  the 
unrestricted  use  of  a  GO  TO. 
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Chapter  4 

l  Stall  EiiJ HEle 

Before  we  describe  the  illustration  system  in  detail,  we 
will  give  a  simple  example  of  a  program  and  some  of  the  resulting 
illustrations  produced  by  the  system  and  the  program.  The 
program  in  figure  4-1  consists  of  a  procedure  RECORD  which  does  a 


linear  search  in  the  array  A 

i 

statistics  in  the  array  SUMS  of  t 
in  A.  If  VAL  is  not  found 
incremented.  The  body  of  the  mai 
A,  SUMS,  and  NO_M ATCH,  and 
conveniently  chosen  values,  one  o 
is  not. 

We  start  with  an  illustrati 
into  the  main  procedure  (figure  4 
procedure  definition  which  sta 
enclosed  in  a  hatched  box  bee 
statements  when  encountered  at  th 
procedure  RECORD  is  replaced  by  " 
page  and  to  exclude  details 
description.  Included,  however 
comment  which  appears  at  th 
definition,  for  this  gives  a  gene 
does. 

Our  first  snapshot  is  insert 
statement.  Since  no  code  has  bee 
as  "?" ,  representing  "undefined". 


,  for  the  value  VAL,  and  updates 
he  number  of  "hits"  for  values 
in  A,  the  counter  N0_ MATCH  is 
n  procedure  merely  initializes 
then  tests  RECORD  with  two 
f  which  is  in  A  and  one  of  which 

on  of  the  first,  and  only,  entry 
-2).  The  declaration  and  the 
rt  the  body  of  the  procedure  are 
ause  they  are  not  executable 
is  level.  Also,  the  body  of  the 
..."  to  conserve  space  on  the 
not  relevant  at  this  level  of 
,  is  the  initial  explanatory 
e  beginning  of  the  procedure 
ral  description  of  what  RECORD 

ed  prior  to  the  first  executable 
n  executed,  all  values  are  shown 
The  first  executable  code  is  a 


loop  to  initialize  the  two  arrays 


This  loop  is  enclosed  in  a 
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hatched  box  because  it  cannot  be  traced  at  this  "level"  and  still 
give  us  a  correspondence  between  program  text  and  execution 
seguence.  Instead,  the  system  treats  its  execution  as  a  single 
event,  prints  a  message  telling  us  how  many  iterations  of  the 
loop  took  place,  and  shows  the  state  of  the  data  a-fter  the  loop 
has  terminated.  If  we  were  sufficiently  curious  about  the 
behaviour  of  the  program  inside  the  loop  (as  we  would  be  i£  the 
loop  were  more  complicated) ,  we  could  ask  the  system  to  give  us 
an  illustration  of  one  or  more  of  those  15  iterations. 

Next,  the  variable  NO_M  ATCH  is  initialized  and  a  new 
snapshot  generated  to  reflect  this.  Then  come  our  two  calls  to 
RECORD.  After  the  first,  we  see  that  the  cell  of  SUMS 
corresponding  to  the  position  of  5  in  A  has  been  incremented  to 
1.  After  the  second,  N0_ MATCH  has  been  incremented.  In  each 
case,  the  end  result  of  the  call  to  RECORD  is  what  we  expected. 

Now  we  would  like  to  examine  the  execution  of  RECORD  in 
greater  detail.  Asking  the  system  to  illustrate  the  procedure 
RECORD,  we  get  figures  4- 3a  and  4-3b.  Note  that  the  messages 
accompanying  the  calls  to  the  routines  in  figure  4-2  form 
"pointers"  to  the  headings  of  figures  4-3a  and  4-3b.  In  figure 
4-3a  we  get  an  initial  snapshot  of  the  data  as  we  left  it  prior 
to  calling  RECORD,  but  with  some  -additions.  We  have  added  the 
variable  VAL,  local  to  this  procedure.  We  have  also  added  a 
representation  of  the  variable  J,  and  requested  that  it  be  shown 
as  a  pointer  to  A  rather  than  by  its  numerical  value.  Since  J  is 
at  this  point  undefined,  it  is  shown  linked  to  a  question  mark. 
Also  new  is  the  second  line  of  the  representation  of  A.  We  have 


asked  that  the  array  be  labeled  with  messages  indicating  whether 


”16** 


the  contents  of  each  cell  of  A  is  equal  or  unequal  to  VAL.  Such 
labeling,  requested  of  the  system  by  a  list  of  predicates  and 
associated  strings,  gives  a  useful  abstraction  of  the  numerical 
data  in  the  array.  The  next  snapshot  appears  after  the  execution 
of  the  loop  inside  RECORD.  The  system  informs  us  that  the 
program  executed  a  return  from  RECORD  and  shows  us  the  state  of 
the  data  when  this  occured.  (Note  the  representation  of  J  as  a 
pointer.)  The  remaining  code  is  shown  in  a  hatched  box  to 
indicate  that  it  was  not  executed  in  this  entry  to  RECORD 
(program  statements  branched  around  by  an  IF  statement  are 
treated  similarly  by  the  system) .  Figure  4-3b  is  much  like 
figure  4-3a  except  that  the  enclosed  loop  terminates  normally  and 
the  procedure  returns  by  encountering  its  END. 

To  request  these  illustrations  from  the  system,  no  change 
was  necessary  to  the  program  text  itself.  Formatting  of  the  text 
and  choice  of  points  for  snapshots  are  determined  by  the  program 
syntax.  All  that  w^s  required  was  to  give  the  system  a  few 
commands  specifying  what  procedure  to  illustrate  (in  the  case  of 
a  loop,  the  loop  must  be  prefaced  by  a  label,  to  be  able  to 
identify  it  to  the  system),  and  what  information  was  to  be 
included  in  the  snapshots.  The  illustration  specification  to 
produce  figure  4-2  consisted  of 

FLO  WGPO  UP  =  TEST; 

V ALU E (NO  MATCH)  ; 

ARRAY(A  (15))  VALUE; 

ARRAY  (SUMS (15) )  VALUE; 

That  for  figures  4-3a  and  4-3b  was  a  little  more  complicated: 

FLOWGROUP  =  RECORD; 

VALUE  (VAL, NO_MATCH)  ; 

ARR  AY_(  A  (  15)  )  POINTERS(J)  VALUE 
LABEL  A (K)  BY 

(A  (K) =VAL: * =VAL' ,  A  (K) -=VAL:  '-=VAL')  ; 
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ARRAY  (SUMS  (15) )  VALUE; 

This  example  is  intended  to  give  the  reader  a  general  idea 
of  the  operation  of  the  illustration  system.  The  next  chapter 
will  give  a  detailed  description  of  the  system. 
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Chapter  5 

Si  the  Ul££t££li£IL  sj£§£e m 

The  aain  component  of  the  illustration  system  is  a 
preprocessor  which  reads  an  SP/k  program  and  an  "illustration 
specification",  or  set  of  commands  to  guide  the  illustration 
process.  The  preprocessor  expands  the  original  program  with 
statements  and  new  variables  to  keep  track  the  program's 
execution  and  to  produce  graphic  output  as  a  by-product.  The 
expanded  program  is  then  compiled  and  executed.  The  expanded 
program  uses  a  graphics  subroutine  package  to  produce  the  graphic 
output  on  an  electrostatic  plotter.  Details  of  implementation  of 
the  illustration  system  are  discussed  in  the  Appendix  to  this 
t  hesis. 
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5. 1  Syntax  of  input  to  the  system  (not  including  run-time  data) 

a  "job"  is:  sp/k  program 
*SPEC 

illustration  spec 

an  "illustration  spec"  is: 

[  FLOWGROUP  =  identifier  ;  ] 

[  CONDITION  =  boolean  ;  ] 

[  ILLUSTRATIONS  =  integer  ;  ] 

[  VALUE  ~(  identifier  {,  identifier  }  )  ;  ] 

{  array  statement  } 

[  CHECK  (  identifier  [  (bounds)  ] 

identifier  [  (bounds)  ]  }  );  ] 

an  "array  statement"  is: 

ARRAY  (  identifier  (  bounds  ) ) 

[  POINTERS  (  identifier  {,  identifier  })  ] 

[  VALUE  ] 

[  LABEL  identifier  (  identifier  )  BY 

(boolean  :  string  {,  boolean  :  string}  )  ] 


a  "bounds"  is:  integer  [  :  integer  ] 

a  "string"  is:  *  any  characters  except  jingle  quote  ' 

a  "boolean"  is  a  boolean  expression  in  SP/k 

Notation:  [  item  ]  means  the  item  is  optional. 

{  item  }  means  zero  or  more  of  the  item. 
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5.  2  Choosing  f  j.ow group- executions  to  illustrate 

For  a  given  program  and  data,  a  separate  "job"  must  be  run 
for  each  flowgroup  from  which  we  desire  illustrations.  The 
FLOWGROUP  statement  identifies  to  the  system  which  flowgroup  we 
wish  to  illustrate.  In  order  to  specify  a  procedure-f lowgr oup, 
use  the  name  of  the  procedure  in  this  statement.  To  specify  a 
loop-flow  group,  the  SP/k  program  must  contain  a  "loop  label"  of 
the  form  /*identif ier :  */  (with  no  spaces  between  *  and 

identifier  or  between  identifier  and  :)  before  the  loop.  If  the 
FLOWGROUP  statement'  is  not  included  in  the  illustration  spec,  the 
MAIN  procedure  of  the  program  is  assumed. 


Once  we  have  identified  the  flowgroup,  we  may  want  to  limit 
the  number  of  illustrations  the  system  will  produce.  The 
CONDITION  statement  allows  us  to  specify  a  boolean  expression 
which  is  tested  at  the  beginning  of  each  execution  of  the 
flowgroup.  This  boolean  expression  must  be  syntactically  correct 
and  its  value  must  always  be  defined  on  entry  to  the  flowgroup. 
If  the  expression  evaluates  to  TRUE  on  entry  to  the  flowgroup, 
the  f lowgroup-execution  will  be  illustrated.  If  no  CONDITION 
statement  appears  in  the  illustration  specification,  then  a 
default  condition  of  TRUE  will  be  used.  The  ILLUSTRATIONS 
statement,  if  included  in  the  illustration  spec,  causes  the 
system  to  count  illustrations  so  far  generated  (with  "permission" 
of  the  CONDITION  statement)  and  to  stop  producing  illustrations 
after  a  specified  number. 
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5 • 3  Specifying  the  contents  and  appearance  of  snapshots 

The  two  datatypes  which  the  system  is  capable  of  displaying 
in  snapshots  are  FIXED  scalars  and  singly-dimensioned  FIXED 
arrays.  Variables  of  other  SP/k  datatypes  may  be  used  in  the 
SP/k  program,  but  may  not  be  included  as  part  of  the  snapshot. 

The  VALUE  statement  specifies  one  or  more  FIXED  scalar 
variables  which  are  to  be  displayed  in  the  snapshot  by  their 
numerical  value.  These  variables  must  be  declared  in  a  scope 
visible  to  the  flowgroup.  These  variables  appear  as  boxes 
showing  the  name  of  the  variable,  and  its  value.  If  the  variable 
is  undefined  at  the  time  of  snapshot  generation,  a  '?'  will  be 
drawn  in  place  of  the  numerical  value. 

The  ARRAY  statement  reguests  the  display  of  a  singly- 
dimensioned  array  as  part  of  the  snapshot.  In  the  program,  the 
array  must,  be  declared  in  a  scope  visible  to  the  flowgroup.  The 
bounds  specified  with  the  array  must  be  the  same  as,  or  a  subset 
of,  the  bounds  declared  for  the  array  in  the  program.  The 
various  subfields  of  this  statement  determine  what  the  display 
looks  like. 

The  POINTERS  subfield  specifies  a  list  of  identifiers  (which 
must  be  declared  as  FIXED  scalars  in  a  scope  visible  to  the 
flowgroup)  which  are  to  appear  as  pointers  into  the  array.  The 
name  of  each  pointer  variable  will  appear  in  the  snapshot  in  a 
box  above  the  picture  of  the  array.  If  the  value  of  the  pointer 
variable  is  within  the  bounds  of  the  array,  a  line  will  point 
from  the  box  containing  the  variable  name  to  the  center  of  the 
appropriate  cell  of  the  array.  If  the  value  of  the  pointer 
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variable  is  over  (under)  the  bounds  of  the  array,  the  line  will 
point  to  the  right  (left)  edge  of  the  picture  of  the  array.  If 
the  value  of  the  pointer  variable  is  undefined,  tbis  line  will 
terminate  in  a  *?'. 


The  VALUE  subfield  of  the  array  statement  specifies  that  the 
numerical  value  of  each  cell  is  to  be  displayed  as  part  of  the 
picture  of  the  array.  If  the  value  of  the  cell  is  undefined  at 
the  time  of  snapshot  generation,  a  '?*  will  be  drawn  in  place  of 
the  numerical  value. 


The  LABEL  subfield  of  the  array-  statement  allows  us  to  label 
the  values  of  the  cells  of  the  array  according  to  assertions  we 
wish  to  make  about  the  values  of  those  cells.  The  subfield 
contains  a  series  of  boolean  expressions,  each  witih  an  associated 
character  string.  For  each  cell  of  the  array,  if  one  of  these 
boolean  expressions  is  true  about  that  cell,  the  cell  is 
labelled,  in  the  snapshot,  with  the  character  string  associated 
with  that  boolean  expression.  The  syntax  of  the  subfield  is 

LABEL  idl  (id2)  BY  (boolean  1 : string  1 ,  boolea n2: string2,  ...) 


idl  must  be  the  name  of  the  array  specified  in  this  ARRAY 
statement.  id2  may  be  any  SP/k  identifier.  Each  boolean 
expression  must  be  a  (syntactically  correct)  boolean  expression 
in  SP/k.  These  expressions  will  be  evaluated  at  snapshot 
generation  time.  The  variable  id2  will  take  on  integer  values 
from  the  lower  to  the  upper  bound  of  the  array.  Using  id2  in 
this  way,  as  a  "parameter"  in  each  boolean  expression,  the  value 
of  each  boolean  expression  must  be  defined  at  any  point  in  the 
flowgroup  being  illustrated.  (These  restrictions  will  be 
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discussed  in  greater  detail  in  section  8.3).  To  generate  the 
array  labelling  part  of  a  snapshot,  the  system,  for  each  cell  of 
the  array,  evaluates  the  series  of  booleans  until  it  finds  a  true 
one,  then  labels  that  cell  of  the  array  with  the  associated 
string.  Adjacent  cells  satisfying  the  same  boolean  will  be 
labelled  in  common  with  one  copy  of  the  associated  strihg.  The 
variable  id2  need  not  be  declared  in  the  SP/k  program,  and  it 
will  not  interfere  with  any  variable  of  the  same  name  declared  in 
a  scope  visible  to  the  illustrated  flowgroup. 

5 . 4  W  here  snapshots  wj.ll  appear 

Having  determined  which  flowgroup-executions,  of  which 
flowgroup,  to  illustrate,  and  the  format  of  the  snapshots  to  be 
produced  in  the  illustrations,  the  system  will  use  the  following 
criteria  to  decide  where  to  break  the  program  text  and  include  a 
snapshot.  A  snapshot  is  provided  before  the  first  executable 
statement  in  the  flowgroup.  After  that  the  following  points  are 
considered  as  candidates  for  a  snapshot: 

-before  an  if  statement 

-after  the  part  of  an  if  statement  which  was  executed 
in  the  f lowgroup-execut ion 

-before  and  after  a  procedure  CALL  statement  (but  not  a 
statement  includina  a  function  call) 

-before  and  after  a  loop  within  the  flowgroup 
-at  the  end  of  the  flowgroup 

At  each  such  candidate  point,  the  system  checks  to  see  if  the 
state  of  those  variables  included  in  the  snapshot  has  changed 
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si  nee  the  last  snapshot  was  generated.  If  such  a  change  has 
taken  place,  a  new  snapshot  is  produced.  The  state  of  all 
variables  requested  in  the  VALUE  and  ARRAY  statements,  or  the 
POINTERS  subfield,  will  automatically  be  checked.  However, 
variables  used  in  the  boolean  expressions  in  the  LABEL  subfield 
are  not  checked  (unless  explicit  display  of  their  value  is 
separately  requested),  although  changing  them  should,  in  some 
cases,  change  the  appearance  of  the  snapshot  (in  the  label  part 
of  the  picture  of  an  array).  The  CHECK  statement  adds  such 
variables  to  the  list  of  variables  checked  by  the  system  for  a 
change  of  state, 

5. 5  Which  text  is  to  be  displayed 

If  the  flowgroup  to  be  illustrated  is  a  procedure,  the  text 
of  that  procedure  is  displayed  in  the  illustration.  If  the 
flowgroup  to  be  illustrated  is  a  loop,  the  text  of  the  innermost 
procedure  containing  that  loop  is  displayed  in  the  illustration. 
In  either  case,  any  procedure  defined  within  the  displayed 
procedure  will  be  shown  in  a  condensed  form.  It  will  be 
represented  by  the  procedure's  header,  any  comments  immediately 
following  the  header,  the  line  and  the  END  of  the 

procedure.  Fpr  example,  the  procedure  RECORD  in  figure  4-2  is  in 
condensed  form. 

5 . 6  R e strict iong  o£  SP/k 

In  this  pilot  implementation  of  the  illustration  system, 
there  are  a  number  of  restrictions  on  use  of  the  SP/k  subset  of 
PL/I.  All  of  these  are  implementation  restrictions  and  are  not 
inherently  imposed  by  the  functional  design  of  the  system. 
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Identifiers  must  not  begin  with  '$'. 

There  are  24  other  identifiers  which  must  not  be  used. 

-(See  A-ppendix  A. 7)  . 

The  BIT  (1 )  variables  TRUE  and  FALSE  are  automatically  pre¬ 
defined  (and  set  to  'O'B  and  '1'B  respectively) 
in  the  scope  of  the  program's  main  procedure. 

They  may  be  used,  but  must  not  be  re-declared  or 
assigned  to  in  any  scope. 

The  system  does  not  completely  check  the  syntax  of  SP/k 
programs,  but.  accepts  a  superset  of  SP/k.  Syntax 
errors  which  are  found  are  poorly  diagnosed  and  not 
repaired . 

Procedures  must  not  be  recursive. 

Run-time  errors  are  not  repaired  and  are  not  reported  in 
the  system  (graphic)  output. 

Semantics,  precision  rules,  conversions,  etc.,  as  well  as 
built-in.  functions,  are  those  of  the  IBM  PL/I 
Optimizing  Compiler, 

Due  to  the  system's  poor  handling  of  compile-  and  run-time 
errors,  it  is  recommended  that  programs  and  data  be  debugged  on 
the  SP/k  compiler  before  being  processed  by  the  system. 
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Chapter  6 
A  Larger  Example 


In  this  section  we  will  take  a  program  and  explore  its 
execution  by  means  of  the  illustration  system,  in  the  hopes  that 
the  system  will  give  us  added  insight  into  how  the  program  works, 
and  give  us  added  confidence  that  the  program  works  correctly. 
The  program  we  will  use  is  a  guicksort  program,  taken,  with  few 
changes,  from  a  standard  introductory  textbook  (Conway  73) . 
Figure  6-1  is  a  listing  of  the  program,  as  listed  and  paragraphed 
by  the  SP/k  compiler.  We  have  labeled  all  loop-f lowg roup s  in  the 
program  by  our  labeling  convention.  The  program  contains  no 
output  statements,  because  our  illustrations  will  tell  us  what 
the  values  of  the  variables  are.  Note  that  there  are  a  total  of 
six  flowgroups  in  the  program.  Funning  this  program  for  a 
"typical"  series  of  20  items  to  be  sorted,  and  adding  some  code 
for  statistics  collection,  we  find  the  following  number  of 
f lowgroup-exec utions  for  each  flowgroup: 


QUICKSORT  1 

SWAP  26 

PARTITION  11 

NLEQK  39 

MOVER  15 

STACK  11 

READIN  20 

ST  23  ■  ' 

total  =  146 

In  our  system,  each  of  these  146  f lowgroup-e xecutions  is  a 
candidate  for  illustration.  Creating  an  illustration  of  each 
would  produce  an  unwanted  information  explosion.  Some 
flowgroups,  like  SWAP  and  READIN,  are  sufficiently  trivial  that 
we  don't  want  illustrations  of  them  at  all.  For  those  we  are 
interested  in,  we  can  use  our  system  to  produce  a  small  set  of 
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illustrations  which  will  give  us  a  good  idea  of  what  the  program 
does. 

Let  us  start  with  an  illustration  of  the  "outermost,, 
flowgr-oup,  QUICKSORT.  Since  the  procedure  is  "called"  only  once, 
we  do  not  have  to  set  up  any  conditions  or  limits  on  whan  to 
illustrate  it.  We  need  only  decide  which  variables  to  include  in 
the  snapshot.  Since  the  various  pointers  and  the  arrays  UPPER 
and  LOWER  are  manipulated  in  other  flowgroups  inside  QUICKSORT, 
we  will  only  try  to  look  at  the  final  result  of  the  program  in 
this  illustration.  We  will  ask  only  for  a  display  of  the  values 
of  the  array  A.  Our  illustration  specification,  then,  is, 

*SPEC 

FLOWGROUP  =  QUICKSORT; 

CONDITION  =  TRUE; 

ARRAY  (A  (20))  VALUE; 

The  first  two  statements  are  actually  unnecessary  because  their 
instructions  correspond  to  system  defaults.  The  third  specifies 
that  we  want  the  snapshot  to  include  the  numerical  values  of 
cells  1  to  20  of  the  array  A.  Giving  the  system  the  original 
program  and  this  illustration  spec  (and  some  values  in  the  run¬ 
time  input  stream)  produces  the  illustration  in  figure  6-2. 

The  illustration  consists  of  program  text,  snapshots,  and 
descriptive  camments,  each  in  a  separate  type  font.  At  the  top 
of  the  page  is  a  line  identifying  the  flow  group-execution  by  name 
and  entry  number.  Next  the  system  prints  some  program  text. 
Variable  declarations  and  procedure  definitions  are  enclosed  in  a 
box  to  indicate  that  they  are  not  executable  statements  in  this 
flowgroup-execution.  Note  also  that  the  bodies  of  the  procedures 
SWAP,  PARTITION,  and  STACK  are  replaced  by  "..."  to  conserve 


-28- 


space  on  the  page.  Comments  preceding  the  bodies  of  these 
procedures  are  included,  however,  to  show,  in  this  outermost 
description  of  the  program,  what  the  procedures  are  intended  to 
do. 

After  these  definitions,  we  come  to  our  first  executable 
statement,  so  we  insert  before  it  our  first  snapshot,  showing  the 
state  of  the  program  before  execution  of  the  f low group-execut ion. 
As  requested,  only  the  values  of  array  A  are  shown,  all 
represented  as  "?"  (undefined).  Note  the  name  of  the  array  to 
the  left  of  the  picture  of  the  array. 

Next  we  come  to  a  loop.  The  loop  is  enclosed  in  a  box  and  a 
message  identifies  the  entry  to  the  loop  and  tells  how  many 
iterations  took  place.  On  completion  of  the  loop,  we  get  a  new 
snapshot,  showing  the  values  of  A  which  have  been  read  in  by  the 
1  oop. 

The  program  text  continues  with  the  initialization  of  our 
stacks  LOWER  and  UPPER  and  with  tiie  "main"  loop  of  the  program. 
We  are  told  that  this  loop  iterated  23  times  and  are  shown  the 
resulting  contents  of  A,  correctly  sorted.  Then  we  are  shown 
that  the  program  terminates  by  encountering  the  END  statement  of 
the  main  procedure. 

Note  that,  according  to  our  rules,  there  were  two  other 
candidate  points  for  snapshots  in  this  flowgroup,  one  before  each 
loop.  ^ t  each  of  these  points,  no  change  has  taken  place  in 
those  data  actually  included  in  the  snapshot,  so  no  new  snapshots 
were  produced. 
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Now  that  we  have  seen  this  first  illustration,  we  decide 
what  to  look  at  next  in  our  exploration  of  the  program  execution. 
We  are  not  very  curious  about  the  READIN  loop,  but  we  would  like 
further  explication  of  the  loop  labelled  ST.  We  are  told  the 
loop  iterated  23  times,  so  we  are  only  going  to  ask  for  the  first 
of  those.  Looking  at  the  program,  we  see  that  this  part  of  the 
program  makes  use  of  not  only  A  but  the  arrays  LOWER  and  UPPER, 
the  variable  M  (used  as  a  pointer  to  LOWER  and  UPPER) ,  and  the 
variables  L,  U  and  K,  used  as  pointers  to  A.  We  will  ask  for  all 
of  these  in  our  snapshot.  In  addition,  since  we  know  that  the 
arrays  LOWES  and  UPPER  are  used  as  stacks  to  keep  track  of 
subranges  of  A,  we  would  like  to  use  our  labeling  facility  to 
indicate  these  subranges  directly  on  the  array.  We  will  use 
labels  SI,  S2,  ...  to  label  the  subranges  that  are  currently 
stored  on  the  first,  second,  ...  locations  of  the  stacks.  It 
would  be  nice  to  express  this  as  "for  the  jth  cell,  if  any  i  <= 
stack  pointer  and  LOWER(i)  <=  j  <=  UPPER  (i),  then  label  the  cell 
with  string  'Si'".  Unfortunately,  strings  used  as  labels  must  be 
expressed  as  constants,  so  we  must  expand  this  labelling 
description  to: 

LABEL  A ( J )  BY 

(H  >=  1  &  LOWER ( 1 )  <=  J  &  J  <=  UPPER (1 ) : ' Si ' , 

M  >-  2  &  LOWER (2)  <=  J  &  J  <=  UPPER(2)  :'S2‘, 

•  •  t 

M  >=  10  &  LOWE R  (1 0 )  <=  J  &  J  <=  UPPER ( 10)  :  'S 10 ')  ; 

C»lls  not  accounted  for  on  the  stacks  will  not  satisfy  any  of 

these  conditions,  and  therefore  will  be  labelled  by  the  null 
string.  Our  complete  illustration  specification  for  this  second 
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*SPEC 

FLOWGROUP  =  ST; 

ILLUSTRATIONS  =  1; 

ARRAY  (UPPER (10))  POINTERS  (M)  VALUE; 

ARRAY  (LOW  ER (10))  VALUE; 

ARRAY  (A  (20) )  POINTERS  (L,  U,  K) 

VALUE 

LABEL  A  (J)  BY 

( M  >=  1  &  LOWER ( 1 )  <=  J  &  J  <=  UPPER  (1 ):' Si  *  , 

W  >=  2  S  LOWER  (2)  <=  J  &  J  <=  UPPER  (2)  :  •  S2»  r 

•  •  « 

M  >=  10  &  LOWER (10)  <=  J  &  J  <=  UPPER (10)  :  'S  10 »)  ; 

The  resulting  illustration  is  shown  in  figure  6-3.  Since  ST 
is  a  loop,  the  heading  at  the  top  of  the  page  identifies  the 
particular  f lowgroup-execution  by  an  (iterations,  entries)  pair. 
Statements  outside  the  scope  of  the  flowgroup  are  enclosed  in  a 
box.  The  first  executable  statement  within  the  flowgroup  is 
prefaced  by  an  initial  snapshot.  The  stack  pointer  II  is  shown 
pointing  to  the  first  cell  of  the  stack  UPPER,  indicating  that 
the  subrange  (1,20)  has  been  stacked.  The  pointers  L,  U,  K  to 

array  A  are  all  undefined.  The  array  A,  in  addition  to 

dispalying  the  value  of  each  cell,  indicates  by  its  labelling 
scheme  that  pointers  to  the  entire  array  have  been  stacked  in  the 
first  location  of  LOWER  and  UPPEP.  In  the  second  snapshot,  the 
pointers  L,  U  to  array  A  have  been  set,  and  the  pointer  M  has 
been  decremented  (any  pointer  value  below  the  lower  bound  of  an 
array  is  displayed  pointing  at  the  left  edge  of  the  picture  of 
the  array).  Since  the  pointer  stacks  are  now  "empty'’,  there  are 
no  labels  on  the  array  A.  After  the  second  snapshot,  the  program 
tests  the  condition  "U  =  L  +  1".  Since  the  condition  is  false, 
the  following  unexecuted  statement  is  enclosed  in  a  box,  to 
indicate  that  it  was  not  executed.  The  call  to  PARTITION  is 
marked  with  an  entry  number,  and  a  snapshot  is  given  of  the  state 
of  the  data  after  the  call. 


In  this  third  snapshot,  we  see  that 
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K  has  been  set  and  the  values  of  A  rearranged.  In  the  fourth 
snapshot,  we  see  the  effect  of  calling  the  procedure  STACK.  The 
stacking  of  the  2  subranges  (1,13)  and  (15,20)  is  shown  both  in 
the  explicit  display  of  the  stacks  and  in  the  labelling  of  array 
A  by  the  strings  "SI"  and  "S2". 

Next  we  would  like  some  illustrations  of  the  procedure 
PARTITION.  PARTITION  works  on  the  subrange  of  A  between  L  and  U, 
so  to  get  a  general  idea  in  a  small  number  of  illustrations,  we 
will  reguest  that  this  subrange  of  numbers  not  be  too  short.  In 
particular,  we  will  ask  that  U  -  L  >  10.  Since  the  stacks  are 
not  manipulated  inside  PARTITION  we  will  not  ask  for  LOWER, 
UPPER,  M,  or  Qur  previous  labelling  scheme  for  A.  Since  the 
pointer  N  to  A  is  mostly  manipulated  inside  the  loop  NLEQK,  we 
will  not  ask  to  see  it  in  PARTITION.  The  illustration  spec  we 
will  use  for  PARTITION  is 

★  SPEC 

FI.OWGROUP  =  PARTITION; 

CONDITION  =  U  -  L  >  10 ; 

ARRAY  (A  (20)  )  POINTERS  (L,  U,  K)  VALUE; 

The  resulting  two  illustrations  are  shown  in  figure  6-4. 
The  header  for  figure  6-4a  matches  the  descriptive  comment  in 
figure  6-3,  the  information  acting  as  a  "pointer"  between  calling 
and  called  code.  The  sequence  of  snapshots  in  each  illustration 
of  PARTITION  shows  the  state  of  the  data  before  and  after 
execution  of  the  loop  NLEQK,  and  the  final  exchange  required  to 
make  the  assertion  "A(L:K-1)  <=  A  (K)  <=A (K+ 1 : U) "  true.  Note  that 
no  program  text  outside  the  procedure  PARTITION  is  displayed  in 
these  illustrations.  Although  the  code  uses  the  global  variables 
L , U , K  and  A,  and  the  procedure  SWAP, 


we  must  look  at  "outer" 
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illustrations  to  find  the  declaration  and  definition  of  these 
variables  and  procedures. 

r 

Now  we  would  like  to  see  what  happens  inside  the  loop  NLEQK. 
We  want  to  see  all  the  iterations  of  an  entry  of  the  loop,  but 
not  too  many,  so  we  note  that  entry  11  of  PARTITION  causes  the 
loop  to  iterate  7  time's.  Since  this  is  a  nice  number  we  ask  for 
these  flowgroup-execut ions  by  the  condition  ' L=1  S  0=13'.  Since 
L  and  U  are  not  changed  i'nside  the  loop,  we  are  assured  of 
getting  all  7  iterations.  Since  the  purpose  of  the  loop  is  to 
partition  the  subrange  into  two  sections,  with  values  <=L  and  >L, 
we  would  like  to  show  this  in  our  labelling.  We  know  that  values 
of  A(j),  for  N <=  j <=K ,  have  not  been  looked  at  yet  in  this  call  to 
PARTITION,  so  we  disregard  t-heir  values  and  label  them  with  •  ?  •  . 
The  remaining  values  of  A  we  label  '<=A  (L)  '  and  *>A(L)*  on  the 
basis  of  their  actual  value,  not  of  their  positions  relative  to  N 
and  K.  Ey  doing  this  we  are  using  our  labeling  system  to  verify 
an  assertion  about  the  program,  although  only  for  this  small  part 
of  our  test  case.  Our  illustration  spec  for  NLEQK  is 

*S  P  EC 

FLOWGROUP  =  NLEQK; 

CONDITION  =  L  =  1  &  D  =  13; 

ARRAY  A  (20))  POINTERS  (L,  U,  N,  K) 

VALUE 

LABEL  A<J)  BY 

<N  <=  J  &  J  <=  K:  '?’ , 

A  (J)  <=  A-(  L)  :  »<=  A(L)  ', 

A  (J)  >  A  (L)  ;  »>A  (L)  •  )  ; 

The  resulting  7  illustrations  are  shown  in  figure  6-5. 
Program  text  inside  PARTITION  but  not  part  of  NLEQK  is  enclosed 
in  boxes.  Reading  through  these  7  illustrations  gives  us  a  good 
picture  of  the  progress  of  the  partition  algorithm.  The  movement 
of  the  pointers  N  and  K  through  the  array  A  is  apparent.  The 
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loop  executes  with  sufficiently  "general"  values  of  data  so  that 
every  piece  of  code  in  the  loop  is  executed  (and  its  action 
demonstrated)  at  least  once.  The  labelling  of  the  array  provides 
a  useful  visual  summarization  of  the  individual  values  of  the 
array . 

The  last  illustration  for  this  example,  figure  6-6,  shows 
one  execution  of  the  procedure  STACK.  The  two  subranges  created 
by  PARTITION  are  placed  on  the  stacks.  The  specification  of  the 
snapshots  is  the  same  as  that  for  figure  6-3. 
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Chapter  7 

Some  related  tools 


7 . 1  Tracing  facilities  provided  by  two  compile rg 


In  any  programming  language  we  are  able  to  augment  a  program 
with  explicit  output  statements  which  cause  run  time  messages  to 
be  printed  explaining  the  state  of  the  computation.  Some 
compilers  can  be  instructed  automatically  to  augment  the  object 
code  to  provide  information  of  this  type.  Such  facilities  are 
called  tracing  facilities.  We  will  briefly  consider  the  tracing 
facilities  of  two  compilers,  the  Algol  W  compiler  (Sites  71)  and 
the  IBM  PL/I  Checkout  compiler  (IBM  72). 


Use  of  the  $DEBUG  option  in  Algol  W  causes  the  program  to 

trace  itself  by  printing  the  text  (and  the  line  number)  of  each 

/ 

statement  as  the  statement  is  executed.  These  statement  copies 
are  accompanied  by  messages  noting  any  new  values  assumed  by 
variables  in  the  course  of  execution  of  the  statement.  The 
$ DEBU G  command  has  a  "multiplicity"  parameter  which  specifies  the 
maximum  number  of  times  any  single  statement  may  be  traced. 
Tracing  may  be  suppressed  or  resumed,  and  the  multiplicity 
parameter  updated,  by  execution  of  the  predefined  procedures 
TRACE  and  UNTEACE.  Tracing  can  be  restricted  to  one  or  more 
nesting  levels  (or  flowgroups,  in  our  illustration  system)  only 
by  laborious  insertion  of  TRACE  and  UNTRACE  procedure  calls. 
Selecting  a  relevant  set  of  variables  to  trace  is  impossible. 
The  Algol  W  compiler  has  the  ability  to  print  a  comprehensive 
dump  of  its  execution  stack,  with  names  and  values  of  all 
variables  by  segment,  points  at  which  segments  were  entered,  and 
the  like,  but  this  output  can  only  be  created  as  a  post-mortem 


dump,  after  a  run-time  error  has  occurred. 
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The  PL/I  Checkout  Compiler  has  the  ability  automatically  to 
monitor  the  updating  of  variables  in  somewhat  the  same  manner  as 
Algol  W.  The  user  may,  however,  specify  those  variables  whose 
updating  is  to  be  monitored,  or  ask  for  all  variables  in  the 
program  to  be  monitored.  Another  feature  of  PL/I  Checkout  is 
that  the  CHECK  facility  (and  its  suppression)  may  be  restricted 
to  a  given  block  or  statement,  by  appending  a  "(CHECK):"  or 
"(NOCHECK) :"  prefix  to  the  statement  or  block.  The  action  of 
these  prefixes  may  be-  overridden  by  calls  to  CHECK  and  UNCHECK 
procedures.  Variable  update  information  generated  by  the  CHECK 
facility  is  not  accompanied  by  copies  of  statements  executed. 
PL/I  Checkout  allows  the  user  to  explicitly  request  a  dump  of  the 
names  and  values  of  all  variables  in  the  execution  environment  by 
means  of  the  "PUT  DATA;"  statement. 

7 . 2  Contour  model  snap  shots 

Recent  work  by  Organick  and  Thomas  has  produced  a  system 
which  automatically  generates  snapshots  of  the  state  of  the 
execution  of  Algol  60  programs  (Organick  74).  These  snapshots 
present  in  visual  form  the  information  present  in  the  execution 
stack  cf  the  program  at  the  time  the  snapshot  is  requested.  Such 
requests  are  made  by  explicitly  including  a  special  SNAPSHOT 
statement  into  the  source  code.  A  new  snapshot  is  generated 
every  time  the  SNAPSHOT  statement  is  encountered  by  the  executing 
program. 


This  contour-diagram  snapshot  approach  is  useful  for 
providing  illustrations  which  explain  and  clarify  the  operation 
of  a  stack-based  interpreter  for  languages  like  Algol  60  or  PL/I. 
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"Hidden"  contexts  and  variables  (which  cannot  be  shown  by  the 
SP/k  illustration  system)  are  included  in  the  contour  diagrams  in 
a  non-confusing  manner.  But  as  a  system  for  conveniently 
generating  displays  useful  for  the  understanding  of  specific 
programs  it  appears  to  have  some  drawbacks.  Finding  the  value  of 
an  identifier  sometimes  reguires  pointer-chasing  and  references 
back  to  the  source  program.  There  is  no  coordinate  system  with 
which  to  relate  snapshots  to  each  other  or  to  the  past  history  of 
the  program.  Always  providing  a  snapshot  of  the  entire  contents 
of  the  execution  stack  relieves  the  user  of  the  necessity  of 
writing  specific  commands  to  guide  the  system,  but  will  often 
cause  the  system  to  produce  an  information  explosion. 

7 . 3  A  mbit /L 


Ambit/L  is  a  language  developed  for  list  processing 
(Wolfberg  70)  .  It  can  manipulate  complex  data  structures,  and 
has  been  used  to  construct  a  system  for  interactive  algebraic 
manipulation.  Its  importance  to  program  illustration  is  that  the 
internal  data  structures  used  by  the  language  are  represented  to 
the  programmer  as  two-dimensional  diagrams.  To  guote  the 
description  of  Ambit/L,  "These  diagrams  are  not  informal  ails  or 
supplementary  documentation;  they  are  the  representations  used 
for  communication  with  the  computer."  The  main  executable  unit 
of  an  Ambit/L  program  is  call  a  rule.  A  rule  is  expressed  as  a 
subdiagram  of  the  data  diagram  and  inciudes  before-after 
information  on  how  the  data  is  to  change  as  a  result  of  applying 
the  rule.  The  Ambit/L  system  is  capable  of  producing  diagram 
output  on  a  line  printer  or  similar  device.  Input  of  diagram 
information  is  by  a  shorthand  notation.  Possibilities  for  future 
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w crk  on  program  illustration  are  suggested  by  aspects  of  Ambit/L. 
Illustration  systems  for  languages  with  more  general  data 
structures,  such  as  the  records  and  references  of  Algol  W,  could 
use  pictorial  conventions  and  layout  algorithms  like  those  of 
Ambit/L  for  displaying  these  data  structures.  It  might  also  be 
possible  to  adopt  Ambit/L-like  conventions  for  showing  changes  to 
data  in  a  single  before-after  diagram  rather  than  in  two 
diagr  ams  * 

7.4  F lowc hartinq 

Flowcharting  is  a  long-established  application  of  computer 
program  visualization.  Many  systems  have  been  built  which 
produce  flowcharts  automatically  from  source  programs  (Abrams 
68).  There  have  been  attempts  to  use  flowcharts  themselves  as  a 
source  language  (Sutherland  66).  A  standard  criticism  of 
flowcharting  has  been  that  the  charts  express  transfer  of  control 
in  terms  of  the  unfashionable  GO  TO  primitive  and  tend  to  obscure 
the  structure  of  other  control  primitives  such  as  loops.  In 
response  to  these  criticisms,  a  number  of  sets  of  rules  have  been 
developed  for  flowcharting  based  on  a  GO  TO-less  set  of  control 
primitives  (Nassi  73) (Hecht  74).  We  can  see  few  advantages  of 
such  flowcharts  over  original  program  text,  if  the  text  is 
automatically  paragraphed,  and  the  paragraphing  is  augmented  by 
other  graphic  conventions  (a  possibility  not  adequately  explored 
in  the  development  of  the  illustration  system) . 

7 .  5  G  rap-h ical  debugging 

Descriptions  of  automated  tools  for  computer  program 
debugging  are  found  in  the  literature  only  infrequently. 


-38- 


Possibilities  for  the  use  of  interactive  computer  graphics  as  an 
aid  to  debugging  are  largely  unexplored.  Some  very  early  work  on 
graphical  debugging  is  described  in  (Stockham  65) .  Some  work  on 
the  display  and  interactive  interrogation  of  complex  data 
structures  is  described  in  (Baecker  68) .  A  simple  debugging 
package  featuring  continuous  updating  of  the  numeric  values  of 
variables,  identified  by  name,  on  a  CRT  display,  is  described  in 


(Petit  71) 
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Chapter  8 

Possible  extensions  to  the  illustration  system 

This  chapter  describes  a  number  of  possible  extensions  to 
the  currently  implemented  illustration  system.  All  of  these 
extensions  would  preserve  the  essential  function  of  the  system, 
and  the  general,  format  of  the  output.  Some  of  the  extensions 
require  modification  of  the  command  language  for  illustration 
specifications.  Most  of  the  extensions  can  be  implemented  using 
the  current  strategy  of  preprocessing  and  augmentation  of  the 
original  program,  although  a  few  reguire  a  different  strategy. 


8.1  Presentation  of  text 


A  number  of  improvements  could  be  made  to  the  overall 
appearance  of  program  text  in  the  illustrations.  The  first  which 
comes  to  mind  is  to  use  the  multiple  font  capability  of  our 
graphic  output  within  the  program  text  itself.  Using  type  fonts 
to  indicate  keywords,  variables,  comments,  etc.  can  substantially 
improve  the  readability  of  a  program.  A  multi-font  convention 
along  these  lines  is  implicit  in  the  definition  of  Algol  60  as  a 
publication  language  (Naur  63)  and  in  the  definitions  of  several 
languages  developed  more  recently.  A  multi-font  convention 
appropriate  to  PL/I  can  be  inferred  from  the  listings  of  XPL 
programs  found  in  (McKeeman  70).  Adding  a  similar  multi- font 
program  text  convention  to  the  illustration  system  would  require 
doing  a  complete  lexical  scan  of  the  source  program,  which  the 
illustration  system . currently  does  not  do.  Consistent  formatting 
of  program  text  within  statements,  as  provided  by  the  SP/k 
compiler  (which  produced  the  text  in  figures  4-1,  6-1,  8-1  and  8- 
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5) f  could  also  be  added  to  the  illustration  system  as  a  by¬ 
product  of  a  complete  lexical  scan. 

One  drawback  of  the  presentation  of  program  text  in  the 
illustration  system  is  the  use  of  the  hatched-box  convention  to 
denote  four  separate,  although  related,  concepts.  The  general 
idea  being  conveyed  by  the  inclusion  of  statements  in  a  hatched 
box,  is  that  the  statements  are  not  being  traced  as  part  of  the 
particular  flowgroup- execution.  The  specific  reasons  for  the  use 
of  hatching  can  be: 

The  statements  are  outside  the  flowgroup  (this  can  only 

happen  for  a  loop-f lowgroup) . 

The  statements  are  declarations  or  procedure  definitions 

(this  can  only  happen  for  a  procedure-flowgroup) . 

The  statements  have  not  been  executed  as  part  of  the 

f  lowgroup-e  xecutior. ,  because  they  have  been  branched 
around  by  an  IF-THEN,  IF-THEN- ELSE,  or  RETURN 

construct. 

The  statements  are  part  of  a  loop  properly  within  the 

flowgroup. 

It  would  be  desirable  to  use  a  different  visual  convention,  with 
enclosing  boxes,  separate  fonts,  different  intensities,  different 
sizes,  or  all  of  these,  to  distinguish  between  these  four  cases. 
Such  a  convention  should  be  designed  carefully  so  that  it  does 
not  introduce  more  confusion  than  it  relieves. 

Another  feature  to  add  to  the  system,  with  regard  to  the 
appearance  of  program  text,  would  be  the  automatic  condensation 
of  those  loops  not  being  illustrated  as  part  of  the  current 
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flowgroup,  in  the  same  manner  as  procedures  are  now  condensed. 
This  would  be  particularly  useful  for  illustrating  large 
programs.  For  a  loop  subsidiary  to  the  flowgroup  being 

illustrated,  the  system  would  print  any  initial  comments  included 
inside  the  loop,  but  replace  the  remaining  body  of  the  loop  with 
as  it  does  now  for  procedures.  Where  the  flowgroup  is  a 
loop,  a  similar  condensation  could  be  applied  to  text  outside  the 
loop  but  within  the  enclosing  procedure.  This  condensation  could 
be  made  an  option  under  control  of  the  user  by  way  of  an 
additional  statement  in  the  illustration  specification. 
Condensation  algorithms  could  be  exten4ed  further  to  take  into 
account  the  total  size  of  an  illustration,  including  snapshots, 
and  apply  sufficient  condensation  of  text  to  make  the 

illustration  fit  on  a  single  page  of  some  specified  dimensions. 

8 . 2  Conditions  for  illustration 

The  ability  of  the  user  to  restrict  the  output  of  the  system 
to  a  small  set  of  relevant  examples  is  a  crucial  one,  if  we  are 
to  avoid  masses  of  unwanted  and  expensive  output  when  making  non¬ 
trivial  tests  of  programs  with  the  illustration  system.  The 
commands  (CONDITION,  ILLUSTRATIONS)  for  doing  this  in  the  current 
system  are  far  from  ideal.  A  first  improvement  would  be  to  allow 
the  user  to  specify  a  series  of  conditions,  and  associate  a  limit 
with  each.  For  example,  if  we  are  interested  in  the  behaviour  of 
a  flowgroup  when  either  condition  A  or  B  is  true,  we  can  use  a 
CONDITION  =  A  |  5  statement  in  our  illustration  specification, 
but  we  may  have  to  generate  many  illustrations  of  executions 
satisfying  A  before  we  find  one  satisfying  B,  or  vice  versa.  Our 
only  reliahle  way  to  illustrate  one  execution  satisfying  each  of 
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the  conditions  would  be  to  run  the  program  twice,  supplying  a 
different  condition  each  time.  This  is  expensive,  as  each  run 
requires  re-compilation  of  the  expanded  source  program.  A  more 
useful  CONDITION  statement  would  let  us  ask  for  "the  first  nl 
executions  satisfying  cl,  the  first  n2  executions  satisfying  c2, 

ft 

•  •  •  • 

An  even  better  approach  would  not  restrict  us  to  conditions 
to  be  tested  at  the  very  beginning  cf  the  loop  or  procedure.  In 
a  loop  such  as 


DO  WHILE  (.  .  .  )  ; 

.  "  R" 

IF  S  THEN 
DO  ; 


up  II 


END  ; 


ELSE 
DO  ; 


•inn 


END; 

END; 

we  would  like  to  tell  the  system  that  we  want  to  illustrate  one 
iteration  causing  execution  of  "P"  and  one  cansing  execution  of 
"Q".  It  may  be  difficult  to  express  this  as  a  set  of  conditions 
to  test  immediately  inside  the  DO  WHILE,  if  ,rR"  influences  the 
value  of  S.  We  would  like  the  system  to  select,  for 
illustration,  executions  which  are  representatives  of  various 
possible  paths  through  the  flcwgroup.  A  listing  could  be 
produced  at  the  end  of  a  run  visually  identifying  those 
statements  traceable  in  the  flowgroup  which  were  never  executed. 
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To  implement  such  a  feature  would  require  some  changes  to 
the  existing  illustration  scheme.  Currently,  the  illustration 
system  decides  at  the  beginning  of  a  flowgroup  whether  or  not  an 
illustration  is  being  generated,  then  outputs  small  sections  of 
that  illustration  as  the  execution  proceeds.  For  our 
"representative"  feature  we  would  need  to  defer  this  decision  to 
a  later  point  in  the  f lowgr oup-execu tion .  Thus  we  need  tne 
ability  to  build  up  part  or  all  of  an  illustration,  then  decide 
whether  to  output  it  or  throw  it  away.  In  our  example  above, 
immediately  inside  the  DO  WHILE  we  would  start  creating, 
internally,  a  picture.  At  the  beginning  of  sections  "P"  ani  "Q" 
we  would  test  a  flag  to  see  if  we  had  executed  that  section 
before.  If  we  had  not,  we  would  set  a  "go  ahead"  flag.  At  the 
very  end  of  the  DO  WHILE  we  would  output  the  internal  picture  or 
throw  it  away  depending  on  the  value  of  the  "go  ahead"  flag. 
Storage  of  these  incomplete  pictures  would  require  either  large 
amounts  of  main  storage,  or  a  compact  internal  representation  of 
the  illustration.  (The  ability  to  store  partial  pictures  and 
defer  their  output  will  prove  useful  for  another  proposed 
extension  discussed  in  8.4.1). 

8.3  Conte nts  and  appearance  of  snapshots 

8.3.1  Labeling 

The  illustration  specification  for  the  Quicksort  example  in 
Chapter  6  demonstrates  some  of  the  awkwardness  of  the  LABEL 
subfield  of  the  ARRAY  statement.  As  we  mentioned,  it  would  have 
been  much  easier  to  write  something  like: 


LABEL  A ( J )  BY 
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(DO  K= 1  TO  20 ; 

M<=K  £  LOWER (K)<=J  S  J  <=  UP  P  E  R  ( K ) : 'S' | |K; 

END';) 

Just  as  great  a  weakness  of  our  labeling  scheme  is  the 
restriction  of  labeling  conditions  to  PL/I  logical  expressions 
which  must  be  defined  at  run  time.  In  illustrating  our  sorting 
program,  we  might  want  to  label  the  elements  of  the  array 
according  to  their  sorted-ness.  A  first  approach,  using  our 
labeling  capability,  might  be: 

ARRAY  (A  (20) )  VAIUE 

LABEL  A (J)  BY 

(A  ( J  —  1 ) <=  A (J)  £  A  (J) <  =  A  (J+1)  SORTED ')  ; 

When  the  system  attempts  to  create  a  snapshot,  the  logical 
expression  will  be  evaluated  for  values  of  J  from  1  to  20.  In 
particular,  for  J=1  the  expression  is  undefined  and  execution  of 
the  program  is  likely  to  be  aborted.  Using  a  more  complicated 
expression  like 

(J  =  1  £  A  (J)  <=  A  (J+1)  ) 

|  ( 1 < J  £  J<2  0  £  A ( J- 1 ) <  =  A  (J)  6  A (J) <=A  (J+1) ) 

|  (J  =  20  £  A  (J-1)  <=  A  (J)  ) 

is  of  no  use  because  PL/I  evaluates  all  terms  of  a  logical 
expression  rather  than  providing  the  "conditional  and  and  or"  of 
other  languages  such  as  Algol  W.  What  is  needed  is  the  ability 
to  specify  our  labeling  condition  (or  our  illustration  condition) 
using  the  general  capability  of  the  PL/I  language.  The  best  way 
to  overcome  the  specific  problem  in  our  example  above  would  oe  to 
include  in  the  original  program,  in  the  same  scope  of  definition 
as  the  array  A,  the  procedure  , 

SORT ED: PROCEDURE (J)  RETURNS  (EIT(1) )  ; 

DECLARE (J) FIXED; 

IF  J=1  THEN  RETURN  (A (J) <=A  (J+1) )  ; 

ELSE  IF  1<J  £  J<  2 0  THEN  RETURN (A ( J-1 ) <= A ( J)  £  A  ( J) <= A  ( J+ 1 )  ) 
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ELSE  IF  J=20  THEN  RETURN  ( A  (J- 1 ) <= A ( J) )  ; 

END; 

and  to  use 

LABEL  A ( J)  BY  (SORTE  D  (J)  SORTED  •)  ; 
in  our  illustration  specification.  This  will  work  in  our  current 
system.  SORTED  may  be  a-dded  to  the  original  program  even  if  it 
is  never  called  in  the  program,  and  the  expression  SORTED  (J) ,  for 
J  from  1  to  20,  is  defined,  provided  the  elements  of  A  are 
defined.  The  only  drawback  is  that  we  have  had  to  substantially 
augment  the  text  of  the  original  program  in  order  to  use  the 
illustrat ion  system.  The  new  procedure  SORTED  will  appear  in  the 
program  text  in  the  illustrations  unless  we  add  another  feature 
to  the  system  specifically  allowing  us  to  exclude  it. 

8.3.2  An  example  of  more  flexible  labeling 

As  an  example  of  improvements  we  can  make  in  the 
specification  of  labeling,  we  will  use  a  program  that  makes  use 
of  more  complicated  data  structures  than  previous  examples.  The 
program  in  figure  8-1  consists  of  a  procedure  (FREE_PIECE)  to  add 
some  space  in  an  array  called  MEM  to  a  free  list  which  is 
maintained  in  the  ^rray.  The  free  list  is  initialized  and  the 
procedure  is  called  4  times  to  test  various  control  paths  through 
the  procedure.  The  pieces  of  the  free  list  can  be  any  size  from 
2  words  to  all  of  MEM.  The  first  location  of  a  free  piece  is 
used  as  a  pointer  to  the  first  location  of  the  next  (in  order  of 
address)  free  piece  in  MEM.  The  second  location  of  a  free  piece 
contains  the  total  length  of  that  free  piece.  The  variable 
FR EE_LI ST_HE AD  points  to  the  first  location  of  the  first  free 
piece  in  MEM,  or  to  zero  if  there  are  no  free  pieces.  An 
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additional  rule  of  management  is  that  no  2  adjacent  free  pieces 
may  be  left  as  separate  pieces  in  the  list.  FREE_PIECE  adds  a 
piece  starting  at  NEW_STAPT,  with  length  NEW^LENGTH,  to  the  free 
list.  It  is  assumed  that  FREE_PIECE  is  only  called  with 
parameters  that  define  pieces  within  MEM  and  not  already  in  the 
free  list. 

We  would  like  to  use  the  illustration  system  to  show 
examples  of  the  execution  of  FREE_PIECE.  We  would  like  the 
snapshots  to  show  which  pieces  of  MEM  are  in  the  free  list  and 
which  are  not.  Clearly,  our  current  labeling  capability  is  ill- 
suited  to  this  task:  inclusion  in  or  exclusion  from  the  free 

list  cannot  be  expressed  as  a  simple  logical  function  of  index 
into  MEM.  The  program  uses  3  variables  as  pointers  to  free 
pieces,  so  for  each  of  these  we  might  try  using 
LABEL  MEM  (K)  EY 

(pointer<=K  &  K<point er+MEM (point er+1 ):' FREE' ) 
to  label  at  least  some  of  the  free  pieces,  but  these  pointers  are 
not  always  defined,  and  they  may  point  to  zero,  causing  the 
logical  expression  to  be  undefined. 

The  only  piece  of  MEM  which  we  can  label  reliably  is  that 
specified  by  the  parameters,  since  we  are  willing  to  assume  that 
the  parameters  are  defined  and  point  to  a  piece  within  MEM.  To 
label  this  segment  as  'NEW'  we  use  the  label  field 
LABEL  MEM(K)  BY 

(NEW_START<=K  &  K <NEW_ST AFT  +  N EW_LENGTH :  » NEW  * )  ; 

We  will  also  assume  that  the  free  list  is  non-empty  whenever 
FPEE_PIECE  is  ealled,  allowing  us  to  use  the  pointer 
FP  EE_L IST_HE AD  to  label  the  first  piece  of  the  free  list. 
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Including  the  pointers  NEW_START,  FREE_LIST_HEAD,  FREE_POINTER 
and  NEXT  in  our  snapshot,  we  get  the  illustration  specification: 

FLOWGROUP  =  FREE_PI ECE; 

ARRAY  (MEM  (80)) 

POINTERS (NEW_START, FR  EE_LIST_HEAD, FR EE_PO INT ER , N E XT ) 

LABEL  M£M  (K)  BY 

(FREE_LI ST_HE AD<=K  8  K<FR EE_LIST_HEAD+ 

MEM  (FR EE_LIST_HEAD+ 11 : ' FIRST' , 

N  EW_START<=K  S ■ K<NE W_STA  RT  +  N  EW_LENG  TH :  ' NEW' )  ; 

The  first  illustration  resulting  from  applying  this  illustration 

specification  to  the  program  is  shown  in  figure  8-2.  Note  that 

in  the  second  snapshot  the  2  labeling  conditions  apply  to  the 

same  piece  of  MEM,  so  the  first  one  is  applied.  note  also,  in 

this  second  snapshot,  how  disappointing  it  is  to  find  NEXT 

pointing  to  a  free  piece  which  we  know  is  there  (from  the  first 

snapshot),  but  to  have  no  way  of  labeling  the  free  piece. 


If  we  were  to  modify  the  semantics  of  our  labeling  construct 
to  check  that  all  terms  in  a  logical  expression  are  defined 
before  evaluating  the  logical  expression,  and  to  treat  the 
expression  as  false  if  undefined  terms  are  found,  then  we  could 
use  the  system  to  display  more  information  in  the  labeling  of 
arrays.  In  particular  we  could  identify,  in  our  example,  the 
free  pieces  pointed  to  by  the  3  pointers  mentioned,  even  though 
the  pointers  are  sometimes  undefined  and  sometimes  do  not  point 
tc  free  pieces.  Figure  8-3  contains  4  illustrations  created  by 
giving  the  system  the  free  list  program  of  figure  8-1  and  the 
illustration  specification 

FLOWGROUP  =  FREE_PIECE; 

ARRAY  (MEM  (80)  ) 

POINTERS ( NEW_ST ART, FR  EE_L IST^HEAD , FREE_POI NTER, NEXT) 

LAE  EL  MEM  (K)  EY 

(  FREE_LIST_HEAD-»=0  &  FR EE_LIST_tfE AD<=K  & 

K<FREE_LIST_HEAD+MEM (FR  EE_LIST_ HE AD  + 1 )  : • FREE', 
FREE_?OINTER-=0  &  FR  EE_FOI NTER<=  K  &  K<FP EE_ POI NT ER+ 

MEM  (FR EE_POI NTE R+ 1 )  : *  FR  EE ' 


$ 
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NEXT-^Q  S  N  EXT<=K  &  K<NEXT  + 

MEM ( NEXT* 1)  :  ’FREE*  r 

NEW_STAR  T<=K  &  K<NEW_ST A RT  +  N EW_L ENGT H :  ' N EW • )  • 

Wp  have  had  to  hand  modify  the  expanded  program  to  apply  our  rule 
of  treating  as  false  those  logical  expressions  containing 
undefined  terms.  (Such  a  feature  could  be  added  to  the  system 
without  too  much  difficulty.)  In  these  illustrations,  we,  still 
cannot  see  all  of  the  free  pieces  at  once,  but  we  can  see  those 
free  pieces  which  the  program  has  access  to  by  way  of  the 
aforementioned  pointers. 


We  could  generalize  our  specification  capability  even 
further,  and  allow  the  user  to  specify,  using  a  general 
programming  notation  (hopefully  the  language  in  which  the 
original  program  is  written),  an  algorithm  for  explicitly 
specifying'  labeling  and  other  aspects  of  the  snapshots.  Such  a 
capability  would  be  the  only  way,  in  the  case  of  our  free  list 
example,  to  make  the  system  identify  all  pieces  of  the  free  list 
in  snapshots,  unless  there  is  built  into  the  system  some  know  lege 
of  our  specific  method  of  building  free  lists.  We  would  like  to 
give  the  system  labeling  instructions  like 

LABEL_ARR  AY_MEM : PROCEDUR  E; 

DECLARE  (I, J,T)  FIXED; 

DO  I=NEW_START  TO  N EW_ST ART +N EW_LENGTH - 1 ; 

LABEL  MEM (I)  BY  'NEW'; 

END; 

T  =  FR  EE  LIST_HEAD; 

J  =  1; 

DO  WHILE  (T->=0)  ; 

DO  I  =  T  TO  T+MEM  (T+ 1) -1  ; 

LABEL  MEM  (I)  BY  (’FREE  ’  |  j  J)  ; 

END  ; 

J= J  +  1 ; 

T  =  MEM  ( T)  ; 

END; 

END  LABE L__ARRAY_ MEM; 
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Hand-modifying  our  expanded  program  for  the  free  list 
example  to  carry  out  this  algorithm  for  labeling  the  array  MEM 
produces  the  illustrations  in  figure  8-4.  The  snapshots  in  these 
illustrations  certainly  tell  us  more  than  those  of  -the  previous 
examples  for  this  program.  One  nright  argue  that  having  to 
specify  a  labeling  algorithm  in  this  great  detail  makes  the 
illustration  system  too  difficult  to  use:  the  illustration 
specification  is  almost  as  complex  as  the  program  we  are  trying 
to  illustrate  (and  just  as  likely  to  contain  errors),  so  using 
the  illustratiop  system  is  more  trouble  than  it  is  worth.  On  the 


other  hand,  the  mechanism  by  which  the  free  list  is  constructed 
is  by  no  means  apparent  from  looking  at  the  program,  and  the  code 
we  have  written  to  specify  labeling  of  the  free  list  is  little 
more  than  a  description  of  how  the  free  list  actually  is 
constructed.  This  description  is  both  less  ambiguous  and  more 
concise  than  any  description  of  our  free  list  which  we  are  likely 
to  write  in  English.  And  a  programmer  who  uses  a  mechanism  of 
such  complexity  that  is  not  built  into  the  language  can  be 
expected  to  give  an  explicit  description  of  the  mechanism 
somewhere  in  conjunction  with  the  program,  if  he  wants  others  (or 
himself  aftpr  a  lapse  of  time)  to  understand  the  program. 
Further  refinement  of  the  illustration  system  developed  here 
could  produce  a  tool  which  was  at  once  a  concise  and  unambiguous 
way  for  a  programmer  to  state  assertions  about  mechanisms  ha  is 
using  and  an  aid  for  visualizing  specific  executions  of  the 
program  in  terms  of  those  assertions. 


We  can  further  extend  our  ability  to  display  data  structures 
built  out  of  simpler  primitives  by  enabling  the  system  to  depict 
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individual  elements  of  an  array  as  pointers  to  that  or  another 
array.  This  is  not  really  necessary  in  our  free  list  example 
because  position,  length  and  order  of  the  pieces  are  all 
indicated  by  our  labeling  scheme.  But  a  more  complicated  or 
redundant  data  structure  (such  as  the  same  free  list  with 
backward  pointers  as  well)  could  be  best  explained  by  showing 
pointers  explicitly.  At  the  same  time  we  might  want  the 
capability  to  ignore  large  parts  of  a  data  structure  and  only 
concentrate  on  a  few  parts.  For  this  we  could  give  the  system 
the  ability  to  replace  part  of  an  array  or  other  data  structure 

V 

with  an  ellipsis.  As  an  example  of  the  use  of  pointers  and 
ellipses,  figure  8-4e  shows  how  we  might  like  our  system  to  draw 
the  second  snapshot  of  figure  8- 4a: .  For  even  as  simple  a  figure 
as  this,  there  is  a  large  amount  of  extra  information  which  the 
illustration  system  must  have  in  order  correctly  to  produce  such 
a  picture  from  the  program’s  data.  The  system  must  be  told 
explicitly  which  parts  of  MEM  are  to  be  left  out,  which  cells  of 
the  array  are  to  be  used  as  pointers,  whether  the  pointers  are 
absolute  or  relative,  whether  lef t- to-right  order  on  the  page 
must  match  address  order  or  that  of  a  sequence  of  pointers,  and 
so  on.  Besides  being  hard  to  communicate  specifications  to,  such 
an  extended  system  would  have  to  incorporate  algorithms  to  solve 
some  very  difficult  layout  problems. 

8.3.3  Da/t a  types 


An  obvious  extension  to  the  system  as  it  stands  would  be  to 
extend  the  range  of  data  types  which  can  be  depicted  in  the 
snapshots.  Character  strings  could  easily  be  added,  as  well  as 
pointers  into  the  strings.  Floating-point  values  for  arrays  and 
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scalars  could  be  added.  Higher  dimensional  arrays  would  present 
more  of  a  problem,  however.  Two  dimensional  arrays  could  be 

included  in  the  snapshot,  but  would  consume  much  space  on  the 

output  page.  They  could  not  be  labeled  the  same  way  one- 
dimensioned  arrays  are.  To  display  a  pointer  into  a  two- 
dimensional  array,  the  user  would  have  to  specify  the  coordinate 
axis  upon  which  the  pointer  was  to  appear. 

8 . 4  Control  structures 

8.4.1  Recursive  procedure  calls 

The  present  system  is  incapable  of  illustrating  the 

recursive  execution  of  a  procedure.  Given  the  basic  definition 

of  the  system,  no  ambiguity  arises  from  illustrating  a  procedure 
that  calls  itself  recursively;  the  problem  is  merely  one  of 
implementation.  An  example,  hand- generated,  shows  what  the 
system  should  do  in  illustrating  the  recursive  execution  of  a 
procedure.  The  program  in  figure  8-5  is  similar  to  the  Quicksort 
program  used  in  chapter  6,  except  that  unsorted  segments  of  the 
array  are  recorded  not  in  explicit  stacks  but  rather  in  the 
implicit  stacks  of  the  recursive  calls.  Figure  8-6  shows  the 
output  the  system  should  produce  if  it  were  given  the  program, 

and  the  illustration  specification, 

\ 

FLOW  GROUP  =  QUICKSORT; 

ARRAY  (A  (7))  POINTERS  (L,K,U)  VALUE; 

The  first,  illustration  shows  the  partitioning  of  the  array 
into  two  segments  and  the  (recursive)  calls  to  QUICKSORT  which 
result  in  a  sorted  array.  The  7  executions  of  this  procedure  are 
numbered  according  to  the  order  of  entry.  Thus  the  two  entries 
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from  the  first  entry  are  numbered  2  and  5,  because  entry  2  gives 
rise  to  two  more  entries  before  it  returns.  Entries  3,4,6  and  7 
are  easily  identified  as  terminating  the  recursive  sequence, 
because  their  calls  to  QUICKSORT  are  not  executed.  Also  note 
that  calls  to  QUICKSORT  from  entry  5  are  not  followed  by 
snapshots,  according  to  the  system's  rule  that  new  snapshots  may 
appear  only  when  the  data  in  them  have  changed  since  the  previous 
snapshot  in  the  same  illustration. 

In  order  for  the  system  to  illustrate  correctly  the 
recursive  execution  of  a  procedure,  the  many  variables  added  by 
the  preprocessor  to  keep  track  of  the  state  of  the  program,  which 
are  currently  declared  globally,  would  all  have  to  be  declared 
local  to  the  recursive  procedure  being  illustrated.  This  would 
be  expensive  of  main  storage.  It  would  also  be  necessary  to  keep 
partial  illustrations,  or  some  condensed  representation  of  them, 
in  main  storage,  until  all  recursive  calls  by  the  procedure  are 
complete.  This  strategy,  and  its  expensiveness,  have  already 
been  noted  in  section  8.2. 

8.4.2  Function  calls 

The  illustration  system  is  capable  of  illustrating  the 
execution  of  a  procedure  which  is  called  as  a  function,  but  it 
does  not  identify  the  entry  number  of  the  procedure  in  the  code 
from  which  the  procedure  is  called.  Fpr  example,  we  would  like 
the  execution  of  the  statement 

A  =  F(X)  ♦  G  (X)  ; 

where  F  and  G  are  defined  as  procedures,  to  be  illustrated  by 
something  like 
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A  =  F  (X)  +  G  (X)  ; 

(ENTRY  5  OF  PROCEDURE  F) 

(ENTRY  10  OF  PROCEDURE  G) 

We  have  noted  the  usefulness  of  these  "pointer"  messages  in 
tracing  the  flow  of  control  through  a  series  of  illustrations. 
In  keeping  with  our  rules,  we  would  not  display  the  values 
returned  from  each  function  call  (these  are  intermediate  results 
within  a  statement)  but  we  might  create  a  new  snapshot  after  the 
statement,  if  the  state  of  the  snapshot  data  had  changed.  A 
closer  syntactic  inspection  of  statements  by  the  preprocessor 
could  easily  reveal,  in  the  statement  above,  the  presence  (and 
order)  of  calls  to  the  procedures  F  and  G,  but  determining  entry 
numbers  of  those  calls  at  run  time  is  impossible,  given  our 
methodology  of  augmenting  the  original  program  but  keeping 
original  statements  intact.  This  inability  is  a  major  drawback 
of  our  preprocessing  approach. 

The  following  example  should  illustrate  the  problem. 

•  •  • 

G:  PROCEDURE  RETURNS  (...)  ; 

•  •  • 

END  G; 

F : PROCEDUR E  RETURN S  (...)  ; 

•  •  • 

IF  ...  THEN  X=G(. ..) ; 

•  •  • 

END  F; 

•  •  • 

(*)  A  =  F  (B  +  F  (C)  )  +  G  (D)  ♦  F(F)  ; 

12  3  4 

•  •  • 

Syntactic  analysis  alone  can  tell  us  that  the  sequence  of  calls 
in  statement  (*)  will  be  2,  1,  3,  4  (ignoring  the  ability,  or 
audacity,  of  some  compilers  to  reorder  this  sequence  in  the  name 
of  optimization).  Before  the  statement,  we  can  determine  what 
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the  next  entry  number  will  be  for  the  functions  F  and  G.  But  we 
cannot  determine,  by  examining  the  state  of  the  program  before 
and  after  statement  (* ) ,  how  to  assign  an  entry  number  to  the 
call  to  G.  A  possible  approach  would  be  for  the  preprocessor  to 
break  statement  (*)  into  an  equivalent  sequence  of  simpler 
statements,  and  to  interleave  these  with  more  statements  to 
examine  state,  but  such  a  task  might  soon  become  as  complex  as 
code  generation,  and  thus  justify  abandoning  the  preprocessing 
approach  and  embedding  the  illustration  capabilities  in  a 
special-purpose  interpreter. 

8 . 5  Checking  of  snapshot  contents 

The  system  as  currently  implemented  does  not  compare  the 

\ 

variables  in  the  illustration  specification  with  those  in  the 
original  program,  but  adds  statements  in  the  scope  of  the 
flowgroup,  assuming  the  variables  requested  are  declared  so  that 
they  are  visible  to  that  scope.  The  system  should  be  made  to 
check  that  these  variables  are  actually  declared  in  the  requested 
scope  and  are  of  the  correct  type,  and  issue  an  error  message  if 
an  inconsistency  is  fognd.  The  system  could  also  get  the  bounds 
of  an  array  from  the  program,  not  from  the  illustration 
specifica tion.  Closer  inspection  of  the  program  text,  not  just 
the  declarations,  could  in  most  cases  automatically  detect  which 
variables  were  being  used  as  pointers  to  which  arrays,  and  not 
require  the  user  to  specify  these  relations  explicitly. 

8 . 6  Other  output  media 


The  graphic  output  produced  by  the  present  system  on  an 
electrostatic  plotter  has  a  number  of  drawbacks.  Generation  in 
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software  of  line  representations  of  individual  characters, 
followed  by  translation  of  this  line  format  to  raster  format  is 
expensive  of  execution  time  and  memory  space.  Resolution  of  the 
electrostatic  plotter  is  sufficiently  coarse  that  characters  must 
be  drawn  larger  than  desired  and  then  the  entire  output  reduced 
to  fit  in  a  page.  Those  aspects  of  the  system  output  which 
depend  on  the  capabilities  of  the  plotter  and  its  software,  e.g. 
multiple  type  fonts,  variable  size  characters,  and  diagonal 
lines,  are  not  absolutely  necessary  to  the  operation  of  the 
system.  Thus  a  more  economical  and  portable  version  of  the 
system  could  me  made,  which  produce  all  its  output  on  a  line 
printer.  Any  extensions  to  the  illustration  system  should 
preserve  modularity  of  the  output  functions  to  allow  modification 
for  the  system  to  support  a  variety  of  output  devices. 
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Chapter  9 

0 the r  possible  approaches  to  the  problem 

This  chapter  describes  two  further  aspects  of  the  problem  of 
the  computer-aided  visualization  of  programs,  aspects  which  our 
illustration  system  does  not  address,  and  which  mere 
modifications  and  extensions  to  the  system  are  not  likely  to 
address.  The  first  section  describes  the  problem  of  visualizing 
a  computation  in  the  general  case,  without  dependence  on  specific 
examples.  The  second  section  discusses  generalization  of  some 
parts  of  our  illustration  system  to  tools  using  interactive 
computer  graphics. 

9 . 1  Visualization  of  the  general  ca se 

As  we  have  mentioned  earlier,  an  eventual  goal  of  a  program 
illustration  system  might  be  to  augment  a  program  with  general 
descriptions,  represented  graphically,  of  the  state  of  the 
computation,  given^  only  a  description  of  the  program  state  at  the 
start  of  the  computation.  This  would  involve  tools  and 
techniques  for  automatic  program  verification  that  are  not 
presently  available,  although  work  in  this  area  continues. 

Using  some  of  the  tools  and  conventions  developed  for  the 
illustration  system,  we  could  construct  a  system  which  produced 
"general"  pictures  of  the  state  of  a  program's  data  from 
similarly  "general"  assertions  about  the  data  suppliejd  explicitly 
by  the  programmer.  Such  a  tool  would  not  seem  too  useful,  and 
the  form  in  which  the  assertions  would  be  stated  would  have  to  be 
rigidly  specified,  but  in  some  cases  pictures  might  prove  to  be  a 
concise  description  of  the  assertion. 
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Act  u  ally  our  current  system  partially  attacks  the  problem  of 
generality  by  providing  array  labeling  and  other  useful 
abstraction  features  in  the  snapshots.  A  labeled  array  separates 
out  useful  information  irrespective  of  specific  data  values. 
Notice  that  the  illustrations  of  figure  8-4  convey  the  desired 
information  without  any. explicit  display  of  data  values.  Each  of 
the  snapshots  in  this  example  represents  an  equvalence  class  of 
many  possible  states  of  the  data. 

By  allowing  us  to  focus  on  the  repetition  of  a  specific  part 
of  the  program,  under  specific  conditions  and  restricted  to  a 
specific  level  of  abstraction,  we  can  get  the  representation  of  a 
sequence  of  states  that  is  a  good  general  picture  of  the 
transformation  accomplished  by  that  part  of  the  program.  For 
example,  quickly  scanning  through  the  7  illustrations  of  figure 
6-5,  we  see  that  the  loop  causes  the  pointers  N  and  K  to  be 
incremented  and  decremented  respectively  until  they  have  crossed 
in  the  inside  of  the  range  (L:U).  Although  this  sequence  has  not 
shown  us  a  good  representation  of  the  possible  cases  of  one  or 
the  other  of  N  or  K  not  changing,  these  cases  happen  relatively 
infrequently.  Also  notice  that  in  -this  sequence  of  7  iterations 
of  the  loop,  all  statements  within  the  loop  are  executed  at  least 
once,  als6  contributing  to  our  "general"  understanding  of  the 
program. 

9 • 2  I nterac ti ve  systems 

Discussion  of  our  illustration  system  and  possible 
extensions  has  assumed  that  the  system  is  non-interactive,  i.e. 
that  there  is  no  possibility  or  need  for  the  user  to  intervene  in 
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the  production  of  the  illustrations  created  by  a  single 
illustration  specification.  Of  course,  rapid  turnaround  time 
will  aid  the  user  in  producing  illustrations  of  a  complex 
program,  since  the  results  of  illustrating  one  flowgroup  are 
useful  in  specifying  the  illustration  of  a  subsidiary  flowgroup. 
Development  of  the  illustration  system  has  suggested  numerous 
ways  in  which  complete  systems  for  the  development,  testing, 
documentation,  storage,  retrieval  and  modification  of  programs 

could  be  built,  taking  full  advantage  of  the  capabilities  of 

-  / 

interactive  computer  graphics.  The  tools  we  will  sketchily 
describe  here  can  be  thought  of  as  compatible  and  harmonious 
components  of  such  a  system. 


9.2.1  A  prog ra m- reading  machine 


We  should  be  able  to  construct  interactive  systems  for 
reading  and  navigating  our  way  through  large  programs,  and 
systems  which  represent  a  substantial  improvement  over  the  use  of 
a  listing  (even  a  nicely  formatted  one)  on  paper.  Good  text 
editors  provide  us  with  many  features  and  commands  which  allow  us 
to  search  through  a  file  of  program  text  to  find  information  we 
are  looking  for,  and  alphanumeric  CRT  displays  are  capable  of 
displaying  new  text  at  a  reasonable  speed.  But  a  computer 
program  has  a  great  amount  of  structure  (dictated  by  its  syntax 
tree,  among  other  things)  which  an  ordinary  text  editor  is 
unaware  of.  A  compiler  finds  all  of  this  structural  information 
as  part  of  its  job;  it  typically  keeps  this  information  to 
itself.  At  best,  a  compiler  communicates  its  representation  of  a 
programs  syntax  tree  to  us  by  syntax-directed  paragraphing  or  by 
a  system  of  "nesting  level"  numbers  appearing  in  a  margin. 
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Programs  could  be  read  more  easily  by  interactively  interrogating 
a  data  base  which  contained  syntax  and  other  information  about 
the  program. 

An  interactive  system  for  such  interrogation  could  use  an 
internal  representation  of  a  program  much  like  that  used  by  the 
preprocessor  for  our  illustration  system.  The  interactive  reader 
might  work  as  follows.  To  look  at  a  procedure,  we  could  first  be 
shown  a  picture  giving  the  names  of  local  variables  within  the 
procedure,  and  an  initial  explanatory  comment.  One  command  would 
cause  to  be  displayed  an  explanatory  comment  about  one  of  the 
local  procedures  (selected  by  pointing  to  it  on  the  screen) . 
Another  would  replace  the  entire  display  with  one  showing  the 
same  preliminary  details  about  a  procedure  local  to  the  procedure 
previously  displayed.  Another  command  could  display  the  text  of 
the  body  of  the  procedure.  If  this  body  did  not  fit  on  the 
screen  at  once,  then  syntactic  entities  such  as  loops  could  be 
shown  in  a  condensed  form,  to  be  expanded  on  the  screen  by  an 
appropriate  command.  The  user  could  pick  a  variable  from  a  menu 
on  the  screen  and  have  all  appearances  of  that  variable  in  a 
piece  of  program  text  be  visually  highlighted  by  blinking  or  some 
such  means.  At  a  more  global  level,  a  tree  or  contour  diagram 
showing  the  hierarchical  relations  between  procedures  could  show 
uses  of  a  global  variable  by  highlighting  those  procedures  in 
which  the  variable  is  accessed.  Capabilities  of  such  a  system 
could  easily  be  elaborated  further. 

Note  that  all  the  information  needed  to  drive  such  an 
interactive  system  is  found  by  a  compiler,  and  can,  without  too 
much  difficulty,  be  reconstructed  from  the  printed  output  of  a 
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compiler,  if  it  includes  such  things  as  nesting  level  numbers  and 
a  cross-reference  table.  Simple  programming  conventions  can 
govern  the  placement  of  comments  in  the  original  program,  so  that 
the  system  jean  retrieve  this  material.  In  addition  to  general 
comments,  other  information  about  the  program  which  cannot  be 
determined  by  syntactic  analysis  (or  cannot  be  extracted  from  the 
compiler)  could  be  communicated  to  the  system  in  comments, 
according  to  some  convention.  For  instance,  we  could  let  the 
system  know  which  procedures  at  a  given  level  are  conceptually 
important  modules  and  which  are  merely  used  for  programming 
convenience.  Displays  of  hierarchical  structure  could  take  such 
a  discrepancy  into  account. 


Such 
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information  at  once.  Extensive  research  into  the  general  problem 
of  paperless  interaction  with  a  large  body  of  structured 
information,  by  way  of  a  CRT  display,  is  described  in  (Engelbart 
68)  . 

9.2.2  A  simple  visual  trace 

The  illustration  system  we  have  constructed  can  be  rather 
easily  generalized  to  a  system  producing  an  animated  sequence  of 
images  on  a  screen,  rather  than  hard  copy.  A  very  simple  version 
of  such  a  system  would  not  require  us  to  illustrate  one  flowgroup 
at  a  time,  or  even  be  conscious  of  flowgroups.  In  such  a  system, 
a  large  area  of  the  screen  would  show  program  text,  a  smaller 
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area  could 

hold 

a  snapshot  like 

those 

produced 

by 

the 

illustration 

system 

(assume  for  now  that 

all 

variables 

in 

the 

snapshot  are  declared  in  the  outermost  block  of  the  program)  .  As 
the  program  executed,  a  cursor  would  move  about  the  program  text, 
showing  which  statement  was  currently  being  executed;  the 
snapshot  would  be  continuously  updated  as  the  program  progressed-. 
The  user  could  use  a  reserved  key  on  the  keyboard  to  step  through 
the  execution  of  statements,  one  at  a  time.  If  the  text  of  the 
program  were  too  long  to  fit  on  the  screen,  the  text  window  could 
be  moved  about  the  program  by  simple  scrolling  or  by  condensation 
and  expansion  based  on  syntactic  structure. 

i 

We  could  extend  the  system  by  allowing  the  user  to  specify 
procedures,  loops  and  other  parts  of  the  program  which  are  not  of 
interest,  and  have  the  detailed  trace  of  these  sections 
suppressed.  We  could  attach  different  snapshot  specifications  to 
different  procedures,  allowing  the  system  to  trace  the  state  of 
local  variables.  We  could  define  conditions  to  be  tested  at 
certain  points  and  automatically  turn  tracing  on  and  off  based  on 
the  values  of  these  conditions. 

Such  an  animated  trace  facility  might  prove  useful  as  a 
debugging  tool,  and  merits  further  experimentation.  But  as  an 
aid  in  understanding  complex  and  unfamiliar  programs,  it  is 
likely  to  have  a  major  drawback  in  that  only  one  picture  of  the 
data  is  shown  at  a  time.  In  order  to  understand  a  complex  change 
in  the  data,  the  user  must  be  able,  for  a  short  time  at  least,  to 
move  his  attention  more  or  less  randomly  between  the  "before" 
state,  the  "after"  state,  and  the  intervening  part  of  the  program 
which  caused  rhe  change.  Our  hard-copy  illustration  system 


-62- 


allows  us  to  make  precisely  such  an  inspection,  whereas  in  a 
system  of  continuous  animation,  even  if  we  were  able  to  control 
speed,  relevant  previous  states  would  be  lost  in  the  flow  of  time 
and  only  retrievable  by  a  har d-to-specif y  and  costly-t o- i mple ment 
backup  procedure. 

In  order  to  be  of  any  use  in  solving  real  problems,  the 
tools  hinted  at  in  this  chapter,  along  with  a  clean  and  quickly- 
responding  (but  not  necessarily  interactive)  version  of  the 
illustration  system,  need  to  be  incorporated  into  a  comprehensive 
and  consistent  programming  system.  A  system  for  computer- 
mediated  writing  and  preliminary  testing  of  programs,  containing 
a  number  of  ideas  useful  for  a  total  programming  system,  is 
described  in  (Snowdon  71).  An  automatic  system  for  insuring  that 
comments,  for  specific  purposes  dictated  strictly  by  the  syntax 
of  the  program,  are  included  in  the  program,  is  described  in 
(Mills  70).  An  example  of  a  language-based  interactive 
programming  system  incorporating  features  for  "program 
composition,  entry,  testing,  debugging,  editing,  optimization  and 
packaging",  and  including  an  example  of  the  sy nt ax- direct ed  text 
editor  hinted  at  in  9.2.1,  is  described  briefly  in  (Bobrow  72) 
and  thoroughly  ip  (Teitelman  74) . 
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Chapter  10 
Conclusion 

In  this  thesis  we  have  described  a  working  prototype  system, 
and  given  both  motivations  for  its  development  and  directions  for 
future  work.  As  a  pre-condition  of  the  development  of  this 
system  we  have  had  to  define  a  terminology  for  describing  the 
execution  of  a  program  based  on  the  syntactic  structure  of  the 
program.  As  a  by-product  of  this  development  we  have  defined 
some  display  conventions,  for  both  program  text  and  data,  which 
should  prove  useful  in  the  development  of  other  programming 

i 

tools.  A  number  of  uses  for  the  system,  especially  if  it  were 
appropriately  ” f leshed-out"  in  some  of  the  directions  indicated, 
are  possible.  Ey  extending  the  range  of  data  types,  adding  the 
error-checking  capabilities  of  a  good  compiler,  providing 
improved  response  time,  and  lowering  the  cost,  a  system  like  the 
one  developed  could  be  used  for  program  debugging.  Similar 
enhancements  could  also  make  it  a  useful  documentation  tool.  A 
more  appropriate  use  for  the  system,  especially  as  presently 
built  to  handle  relatively  simple  programs,  would  be  for 
instruction  in  beginning  programming,  both  as  a  generator  of 
useful  teaching  aids,  and  as  a  tool  for  students  to  visualize  the 
execution  of  programs  they  themselves  had  written. 
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Appendix 

A  brief  description  of  the  implementation  of  the  illustration 
system 

A •  1  The  preprocessing  approach  and  its  alternatives 


The  illustration  system  accomplishes  its  task  of 
illustrating  the  execution  of  a  program  as  follows.  It  takes  the 
original  program,  and,  guided  by  information  in  the  illustration 
specification,  expands  the  program  with  statements  to  keep  track 
of  its  own  execution  and  to  produce  graphic  output  as  a  by¬ 
product.  This  expanded  PL/I  program,  containing  calls  to  the 
graphics  subroutine  package  ZAPP,  is  then  compiled  by  the  PL/I 
optimizing  compiler  and  the  resulting  program  executed  (Guerin 
73) (IBM  72) .  The  program  to  perform  the  expansion,  called  the 
preprocessor,  is  written  in  the  SN0B0L4  language,  using  the 
SPITBOL  compiler  (Griswold  71)(UTCC  72).  The  preprocessor 
interleaves  new  code  into  the  original  program,  but  does  not 


delete  any  of  the  text  of  that  program.  All  simple  statements  of 
the  original  program  are  left  intact  by  the  preprocessor.  Thus 
we  have  the  limitation  that  the  state  of  the  execution  of  the 
original  program  can  only  be  examined  between  statements  of  that 
program. 


One  alternative  to  the  preprocessor  approach  would  be  to 
create  a  compiler  and  interpreter  for  the  language  involved  and 
add  sufficient  logic  to  the  interpreter  to  carry  out  the 
illustration  process.  This  would  be  a  difficult  task  if  we  were 
to  start  from  scratch,  but  would  be  a  worthwhile  alternative  to 
consider  if  a  working  and  easily  modifiable  compiler/int erpr eter 
for  the  desired  language  were  available.  Due  to  the  dependence 
of  the  illustration  process  on  the  syntax  of  the  source  program. 
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it  would  probably  be  necessary  to  substantially  augment  the 
compiler  as  well  as  the  interpreter  in  such  a  system.  The 
advantage  of  the  compiler/in terpret^r  approach  would  be  that  more 
information  about  the  state  of  the  program’s  execution  would  be 
accessible  to  the  illustration  process.  Using  the  preprocessing 
approach,  we  can  only  display  state  which  is  "visible  to  the 
program  itself". 


For  example,  given  the  current  system  and  the  following 
prog  ra  m: 

P : PROCEDUR  E  OPTIONS (MAIN) ; 

DECLARE (X,Y)  FIXED; 

Q : PROCEDURE  (X) ; 

DECLARE  ( X)  FIXED; 

•  t  • 

END  Q; 

•  •  • 

CALL  Q  (Y) ; 

•  •  • 

END  P; 
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we  are  tracing  the  execution  of  Q,  we  can  add  state 
examine  the  value  of  the  X  in  Q,  but  not  to  determ 
of  the  X  declared  in  P,  or  to  determine  that  the  X 
lly  a  reference  to  the  Y  in  P.  If  an  interpreter 
e  of  illustration,  we  could  examine  the  execution  s 
mine  such  information.  On  the  other  hand,  inclusion 
mation  in  the  snapshots  would  require  more  complexit 
1  display  conventions  and  in  the  command  languag 
nt  restrictions  on  snapshot  information,  although  im 
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A . 2  Overall  organization  of  the  preprocessor 


The  preprocessor,  a  SNOBOL4  program  of  roughly  1100 
statements,  has  4  distinct  phases  of  operation,  or  passes.  The 
first  pass  is  to  read  and  parse  the  original  SP/k  program.  The 
results  of  this  gpass  are  a  character-string  array  containing  the 
complete  program  as  paragraphed  by  the  SP/k  paragraphing  rules 
(except  for  formatting  within  statements,  see  section  8.1),  and  a 
syntax  tree  whose  terminal  nodes  are  pointers  into  this  array  of 
text.  The  second  pass  reads  the  illustration  specification  and 
produces  an  internal  representation  of  that  specification.  The 
third  pass  examines  the  syntax  tree  and  the  (internal) 
illustration  specification  and  generates  the  expanded  program, 
which  will  be  compiled  and  executed.  The  fourth  pass  generates 
the  file  of  text  which  the  executing  expanded  program  will  use  to 
include  portions  of  the  original  text  in  the  graphic  output. 

i 

A . 3  Fe adi  ng  and  parsing  the  SP/k  program 
A . 3 . 1  Recursive  descent  parsing 


The  SP/k  subset  of  PL/I  was  designed  as  a  convenient  subset 
of  PL/I  for  educational  purposes.  It  was  also  designed  to  be 
cheaply  i mplementable.  In  particular,  the  language  subset  can  be 
parsed  by  a  simple  top-down  parser.  While  the  SP/k  compiler  uses 
a  table-driven  top-down  parser  with  facilities  for  syntax  error 
recovery  and  correction,  the  subset  can  be  parsed  with  a 
recursive  descent  parser  without  the  use  of  backup,  if  we  are 
willing  to  forego  error  recovery.  The  preprocessor  parses  the 
original  program  using  such  a  recursive  descent  parser  (see 
section  2  of  (McKeeman  73)) .  The  syntax  description  of  SP/k 
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includes  paragraphing  rules  embedded  into  the  syntax  productions, 
and  these  are  used  by  the  parser  to  produce  the  paragraphed 
program  text  as  a  by-product  of  parsing.  The  parser  in  the 
preprocessor  only  does  a  partial  parse  of  the  original  program. 
Syntactic  details  not  relevant  to  the  illustration  process  are 
not  checked  by  the  preprocessor.  For  example,  when  the 
preprocessor  is  examining  a  statement,  if  it  determines  that  the 
statement  must  be  either  an  assignment  or  syntactically 
incorrect,  it  scans  to  the  next  semicolon  (not  inside  a  comment 
or  string)  and  ignores  the  body  of  the  statement.  Thus  a  large 
body  of  syntax  errors  are  not  detected  by  the  preprocessor. 

A. 3. 2  Structure  of  the  syntax  tree 


The  syntactic  structure  of  the  original  program  is  stored  in 
a  syntax  tree.  This  tree  is  built  up  out  of  programmer-defined 
data  type's.  There  are  4  record  types  corresponding  to  syntactic 
entities  which  are  control  constructs  of  significance  to  the 
illustration  system.  These  4  record  types  correspond  to  the 
procedure,  loe>p,  do,  and  if-then- (else)  constructs  of  SP/k.  Two 
other  record  types  are  used  in  the  syntax  tree.  One  (LISTNODE) 
is  for  building  lists  of  records  corresponding  to  seguences  of 
statements  in  the  program.  The  other  (TEXTNODE)  contains 
pointers  into  the  array  of  program  text,  and  is  used  to  represent 
simple  statements  and  other  pieces  of  text.  Other  information 
useful  to  the  preprocessor  is  maintained  in  the  syntax  tree. 


structure  of  the  syntax  tree,  we 
of  the  record  types,  PROCNODE 


As  an  example  of  the 
describe  the  form  of  one 
(representing  a  procedure). 


used  to  make  up  the  tree.  PROCNODE 
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has  7  fields.  The  NAME  field  holds  a  character  string,  the  name 
of  the  procedure.  The  HEAD  field  points  to  a  TEXTNODE  record, 
which  in  turn  delimits  the  header  line  of  the  procedure  in  the 
original  program  text.  The  DECL  field  points  to  a  TEXTNODE 
record,  which  in  turn  delimits  all  declaration  statements  local 
to  the  procedure,  in  the  original  program  text.  The  LOCALS  field 
points  to  a  list  (constructed  by  means  of  the  LISTNODE  record)  of 
strings  holding  the  names  of  variables  local  to  the  procedure. 
The  PFOCS  field  points  to  a  (possibly  empty)  list  of  FROCNODE 
records,  representing  procedures  declared  within  the  procedure. 
The  BODY  field  .points  to  a  list  of  records  of  various  types, 
representing  the  statements  in  the  body  of  the  procedure.  The 
TAIL  field  points  to  a  TEXTNODE  record  delimiting  the  END 
statement  of  the  procedure  in  the  original  program  text.  Note 
that  the  NAME  field  is  redundant  (because  the  name  can  be 
extracted  from  the  header  line  in  the  text)  but  useful  when 
searching  the  entire  tree  for  a  procedure  of  a  given  name.  The 
information  pointed  to  by  the  LOCALS  field  is  similarly 
redundant . 

A. 4  Reading  the  illustration  specif ication 

The  second  pass  of  the  preprocessor  is  to  read  the 
illustration  specification  and  store  it  in  a  tree-like  internal 
form  using  programmer-defined  record  types.  Given  the  name  of 
the  flowgroup  to  be  illustrated  (as  part  of  the  illustration 
s peci f ica tion) ,  the  preprocessor  sets  2  pointers  into  the  syntax 
tree,  one  to  the  node  corresponding  to  the  flowgroup  itself,  and 
one  to  the  procedure  node  corresponding  to  the  procedure  egual  to 
or  immediately  enclosing  the  flowgroup.  This 


allows  the 


-69- 


preprocessor  to 
mentioned  in  the 


partition  the 
next  section 


syntax  tree  into  the  3  regions 


A .  5  Generating,  the  expanded  program 


Once  the  syntax  tree  is  built  up  and  the  illustration 
specification  stored,  the  preprocessor  is  ready  to  generate  the 
expanded  program  by  traversing  the  syntax  tree.  This  traversal 
of  the  tree  is  a  recursive  process  analogous  to  the  recursive 
parsing  which  builds  the  tree.  For  purposes  of  this  traversal, 
the  tree  (and  the  program  it  represents)  may  be  thought  of  as 
divided  into  3  regions:  those  parts  of  the  tree  and  program 
outside  the  flowgroup,  those  inside  the  flowgroup,  and  those 
inside  subsidiary  flowgroups  within  the  flowgroup  being  traced. 
Program  text  in  all  of  these  regions  is  augmented  by  statements 
generated  by  the  preprocessor,  but  it  is  in  the  second  region 
that  the  code  responsible  for  the  actual  production  of 
illustrations  is  generated. 


A . 5. 1  Tra nsf or mat ions  of  the  illustrated  code 

In  the  "illustrated"  region  of  the  original  program,  the 
various  control  structures,  as  encountered  in  the  traversal  of 
the  syntax  tree,  give  rise  to  specific  augmentations  of  the 
program  text  which  cause  the  program  to  keep  track  of  its  own 
behaviour.  As  an  example,  we  will  show  how  a  simple  IF  statement 
would  be  expanded  if  it  were  in  the  "illustrated"  region  of  the 
program.  Here  is  a.  statement,  as  it  would  be  paragraphed  and 
stored  away  in  an  array  by  the  first  pass  of  the  preprocessor: 
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IF  A<B  THEN  20 

A=0 ;  21 

ELSE  22 

B=0 ;  23 


After  expansion  by  pass  3  the  statement  might  look  as  follows 

(added  code  is  shown  in  lower  case  for  clarity) : 

if  $displaying  then 
do; 

call  $text ( {lastline, 1 9, 0) ; 
if  {changed  then 
call  {snapshot; 
end ; 

{test  (2) =  A<B  ; 

$lastline=20 ; 

IF  A< B  THEN 
do; 

A  =  0; 

if  {displaying  then 
-  do; 

call  $te xt (Slast line, 21 , 0) ; 
if  {changed  then 
call  {snapshot; 
end; 

end  ; 

ELSE 

do; 

if  {displaying  then 
do ; 

call  {text  (20, 20 , 0) ; 
call  {text  (21,21,1) ; 
call  {text  (22,22,0) ; 
end  ; 

Slastline=23 ; 

B=0  ; 

if  {displaying  then 
do ; 

call  {text  ({ last  line , 23 , 0)  ; 
if  {changed  then 

call  {snapshot;  '• 

end ; 

en  d ; 

if  {displaying  &  {test  (2)  then 
do ; 

call  {text (22 , 22 ,0)  ; 
call  {text  (23 , 23 ,  1 )  ; 
end  ; 

{displaying  is  a  flag  (set  at  the  beginning  of  the  flowgroup- 
execution)  which  tells  whether  the  current  execution  of  the 
flowgroup  is  producing  output.  {changed  is  a  function  which 


tells  if  the  data  in  the  snapshot  have  changed  since  the  last 
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snapshot.  Ssnapshot  is  a  procedure  which  generates  a  new 
snapshot.  The  procedure  $text(a,b,c)  includes  in  the 
illustration  lines  a  through  b  of  the  original  program,  and 
encloses  them  in  a  hatched  box  if  c=1.  Ilastline  is  an  integer 
variable  used  to  record  the  number  of  the  first  line  of  text  not 
already  printed  by  a  call  to  $text.  Examination  of  this  program 
fragment  will  show  that,  for  either  possibility  of  the  condition 
A <3 ,  the  expanded  program  will  print  the  4  lines  of  the  original 
program  in  the  illustration,  with  the  unexecuted  branch  of  the 
condition  enclosed  in  a  hatched  box. 

A. 5. 2  Declarations  and  initializations 


The  illustration  system  creates  a  number  of  its  own 
variables  which  are  used  in  the  expanded  program.  These  system- 
created  variables  always  begin  with  the  character  * $',  so  that 
they  do  not  interfere  with  variables  declared  in  the  original 
program,  (Of  course,  the  rule  against  starting  variables  with  '$' 
is  followed  in  the  original  program.)  These  variables  serve  a 
number  of  purposes.  Some  are  references  to  ZAPP  pictures  (see 

A. 7).  Some  keep  track  of  the  past  history  of  the  program  and 
allow  us  to  number  f lowgroup-executions  by  our  coordinate 

systems.  For  each  variable  included  in  the  snapshot,  another 
variable  is  created  by  the  preprocessor  to  store  its  value  at  the 
last  point  when  a  snapshot  was  generated,  allowing  us  to  test 

easily  at  run  time  whether  the  variables  in  the  snapshot  have 


changed,  and  to  suppress  the  display  of  redundant  snapshots. 
Other  created  variables  hold  parameters  and  state  information  to 
guide  the  layout  of  the  illustrations  on  the  page. 
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The  illustration  system  also  creates  initialization  code  to 
initialize  some  of  the  variables  it  has  created.  Graphic 
information  which  will  be  used  repeatedly  by  the  illustration 
system,  templates  and  identifier  names,  are  created  in  the 
initialization  part  of  the  expanded  program  and  used  repeatedly 
in  the  expanded  progranu  The  system  implements  the  detection  of 
undefined  variables  by  initializing  all  variables  (except 
parameters)  included  in  the  snapshot  to  a  "magic"  value  (the  most 
negative  number  possible  for  the  type)  on  entry  to  the  procedure 
in  which  they  are  defined. 

A. 5, 3  Independent  and  dependent  procedure s 


A  set  of  14  PL/I  procedures  is  used  by  the  expanded  program 
to  carry  out  various  tasks  in  the  construction  of  the 
illustrations.  The  text  of  these  procedures  is  independent  of 
the  particular  program  and  illustration  specification  presented 

to  the  preprocessor.  These  procedures  constitute,  in  effect,  a 

/ 

run  time  support  package.  The  source  text  for  this  group  of 
"independent"  procedures  is  always  included  in  the  outermost 
scope  of  the  expanded  program.  .Two  other  subroutines,  SCHANGED 
and  $SNAPSHOT,  are  created  by  the  preprocessor  because  they 


reference  (as  global  variables)  the  variables  in  the  original 
program  which  are  to  be  displayed  in  the  snapshots.  Since  they 
must  access  the  same  variables  as  does  the  flowgroup  being 
illustrated,  these  2  procedures  are  placed  in  the  innermost  block 
containing  (or  equal  to)  the  illustrated  flowgroup. 
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A.5.4  Size  of  the  expanded  program 

Expansion  by  the  preprocessor  of  the  program  described  in 
section  8.3.2  results  in  a  PL/I  program  of  635  statements  (as 
counted  by  the  IBM  PL/I  compiler) .  The  support  package,  not 
including  its  many  global  declarations,  was  260  statements  long. 
The  $CH AN GED  and  SSNAPSHOT  procedures  were  60  statements  long. 
The  illustrated  flowgroup,  33  statements  long  in  the  original 
program,  was  expanded  to  a  total  of  150  statements.  80 
statements  were  added  by  the  preprocessor  for  global 

initialization. 

■ 

A . 6  Generating  the  conden  sed  source  text 

The  final  pass  of  the  preprocessor  is  to  generate  a  file  of 
lines  of  the  original  program  which  will  be  accessible  to  the 
execution  of  the  expanded  program.  Only  those  statements 
appearing  in  the  illustration  are  included  in  this  condensed 
source  text  tile,  so  the  contents  of  this  file  are  a  function  of 
the  FLOWGFOUP  statement  of  the  illustration  specification  as  well 
as  of  the  original  program.  Additional  information  to  aid  layout 
of  program  text  in  the  illustrations  is  also  included  in  this 
file. 

A . 7  Outputting  the  illustrations 

The  ZAPP  picture  package  is  used  to  generate  the  graphic 
outpuf  from  the  system.  ZAPP  is  a  collection  of  procedures 
callable  from  a  number  of  languages,  in  particular,  PL/I. 
Although  designed  for  the  production  of  animated  films,  ZAPP  can 
also  be  used  to  produce  single  pictures.  A  procedure,  FONTS,  to 
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create  ZAPP  pictures  which  are  characters  in  a  variety  of  type 
fonts,  is  available.  At  time  of  writing,  FONTS  is  incapable  of 
drawing  some  characters  in  the  PL/I  character  set.  These 
characters  must  be  added  to  the  graphic  output  by  hand.  Output 
from  ZAPP  may  be  sent  to  line  plotters,  a  microfilm  point 
plotter,  or  to  an  electrostatic  point  plotter.  All  output  from 
the  illustration  system  uses  the  electrostatic  plotter. 

Since  the  JSNAPSHOT  procedure  must  be  defined  at  an  inner 
scope  of  the  expanded  program,  and  SSNAPSHOT  makes  use  of  the 
ZAPP  (external)  procedures,  and  the  ZAPP  procedure  names  do  not 
conform  to  the  ’$*  convention,  we  have  an  added  r-estriction  that 
variables  in  the  original  program  not  have  the  same  names  as  the 
ZAPP  procedures  used  in  the  expanded  program.  These  names  are 
A  EVANS ,  CLOSEP,  CONCAT,  COPY,  CUTODT,  DELET,  DRAW,  FINISH,  FL INR , 
FONTS,  GROPEN,  HATCH,  INFORM,  INTENS,  LINES,  LINETO,  MOVEEY, 
MOVETO,  OPEN?,  PAN,  PLOTSS,  POINTS,  SIZEF,  SIZEFP,  and  SPECS. 
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/*  LINEAR  SEARCH  PROGRAM  FCR  I l LLSTPAT ICN  */ 

1  TEST  iFRCCECURE  CPT  ICNS  CH'AlfN)  : 

2  DECLARE(A(  15)  tSLNSl  15)  ,NC_NATCH,I) FIXED: 

3  RECORD:  FPCCECURt  (VAL  )  : 

/*  FI  NCS  VAL  IN  AO,  */ 

/*  INCREMENTS  CORRESPONDING  ENTRY  CF  SUMS (  )  */ 

/*  IF  VAL  NOT  IN’  AO,  INCREMENTS  NO_  MATC  H  v  / 

4  DECLARE (J,VAL)F  IXEC; 

5  CO  J=1  TO  15: 

6  IF  A  (  J  J  =  VA L  THEN 

7  DC; 

8  SUMS! J)=SUMS( J)+l; 

9  RETURN: 

10  END; 

11  END; 

12  NC_NATCF  =  NC_MATCH+1  : 

13  END: 

/*  INITIALIZE  A (  ) ,  SUMS (  )  ,  NO_MATCH  */ 

14  DG  1=1  TO  15; 

15  GET  LI S T ( A ( 1 J  )  : 

16  SUMS (I  )  =  0  ; 

17  END; 

18  N  C_  M  A  T  C  F  =  C  ; 

/*  TEST  PFCCECURE  RECORD  TWICE  */ 

19  CALL  R  EC  C  RD ( 5  ) ; 

20  CALL  RECORD ( 6  )  ; 

21  ENC; 

22  SCAT  A 

END  CF  COMPILATION.  25C  BYTES  OF  CODE  GENERATED. 

-  \ 

EXECUTICN  EEGINS. 


ENC  CF.  EXECUTICN.  204  BYTES  OF  DATA  AREA  USED. 

90  STMTS  EXECUTED.  0  LINES  CUT  PUT •  0  EPRCPS. 


figure  4-1 


ENTRY  1  OF  PROCEDURE  FEET 

E5T:  PROCEDURE  OPTION. '( MAIN); 

DECLARE  (A(J5);  yUMS'dr,),  NO_MATCH,'  I)  FIXED;"  “/""T'"  /r 
RECORD  PROCEDURE  VAL);  '  ,  '  /"  /' 

r  /*  FINDS  VAL  IN  A().  */ 

/"  INCREMENTS  CORRESPONDING  ENTRY  OF  SUMSf)  V 
f  /*  IF  VAL  NOT  IN  A().  INCREMENTS  NO  MATCH  */  '  / 


MO.MATCH 

7 


Al  ? 

? 

? 

? 

7 

7 

7 

7 

7 

7 

7 

7 

7 

?  i 

SUMS  |  ? 

7 

7 

7 

7 

7 

7 

7 

? 

? 

7 

7 

o 

7 

J*  1NIT1AIJZE  A(),  SUMS(),  NO  MATCH  */ 
DO  1=1  TO  15;  , 

!  '  GET  L1ST(A(I)); 

!  sums(I;  =  o.  - 
END; 


(ENTRY  1  OF  LOOP  ) 
LOOP  ITERATES  15  TIMES 


NO-MATCH 

? 


Al  44 

75 

35 

12 

74 

97 

24 

3 

80 

1 

42 

5 

63 

3D 

23  1 

SUMS  [  0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

-P.  1 

NO-MATCH  =  0; 

/*  TEST  PROCEDURE  RECORD  TWICE  ♦/ 


HO- MATCH 

0 


A|  44 

75 

35 

12 

74 

97 

24 

3 

80 

1 

42 

5 

63 

30 

23  j 

SUMS |  0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

-0-  1 

CALL  R2C0RD(5); 


(ENTRY  1  OF  PROCEDURE  RECORD) 

NO-MATCH] 

-  0-  -  ) 


i  44 

75 

35 

12 

74 

97 

24 

3 

EO 

1 

42 

cr 

63 

30 

23  1 

l.-P 

0 

0 

0 

0 

C 

0 

,  0 

0 

0 

0 

1 

C 

0 

Gj 

CALL  RZC0RD(6); 


(ENTRY  2  OF  PROCEDURE  RECORD) 

NO  MATCH! 

1  1 


aL 

44 

75 

35 

12 

74 

97 

24 

3 

80  ’ 

1 

42 

5 

63 

30 

23  1 

SUMS  L 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

1 

0 

0 

0  J 

END; 

PROCEDURE  TEST  RETURNS 


figure  4-2 


ENTRY  1  OF  PROCEDURE  RECORD 

ECCRD:  FROCEDL'RE(VAL); 

/*  FINDS  VAL  IN  A().  */ 

/*  INCREMENTS  CORRESPONDING  ENTRY  OF  5UMS()  */ 

/»  IF  VAL  NOT  IN  AQ.  INCREMENTS  NO_V_ATCH  •/ 

DECLARE  0.  VAL)  FIXED; 


VAL1 

NO  .MATCH 

5 

0 

P 


1 


44 

75 

35 

12 

74  97 

24 

3 

80 

1 

42  5  63  30 

23  1 

Al 

i=VAL 

1  =VAL  1  -i=VAL 

1 

sums  L 

0 

0 

0 

0 

0  0 

0 

0 

0 

0 

o 

o 

c 

i 

1 

°j 

0 J 

iDO  4=  1  "TO  15;  "7 . /  “  7  “V "  ~7~ 

'  IF  A(J)  -  VAL  THEN  /'  /  /'  / 

f  DO;  ./  /  /  / 

j  /  /  SUMS(J)  =  SUMS(J)  +  1;  ,/" 

'  '''  RETURN;  / 

'  .  END; 

r'  END;  / 

.  '  "  {ENTRY  1  OF  LOOP  ) 

LOOP  ITERATES  12  TIMES 

RETURN  FROM  PROCEDURE  RECORD  ON  LAST  ITERATION 
LEAVINC: 


VAL 

N0 MATCH 

5, 

0 

□ 


A 

SUMS 


44 

75 

35 

12 

74 

97 

24 

3 

80 

1 

42 

5  63  30 

23 

"t=VAL 

|  =VAL  1  ~i=VAL 

o 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

1  0  0 

0 

rNOl;J^TCH  =  NC_AL4TCH  +  1; 
END;. _ _ /  /  / 


J 


A 


f igure  4-3a 


ENTRY  2  OF  PROCEDURE  RECORD 

RECORD:  EROCEDURS(VAL); 

/•  FINDS  VAL  IN  A(),  >/ 

/•  INCREMENTS  CORRS5PONDTNO  ENTRY  OF  SUMS()  */ 

/*  IF  VAL  NOT  IN  A().  INCREMENTS  NO-MATCII  */ 

DECLARE  (J.  VaL)  FIXED; 


VAL 

6 


NO-MATCH 
0 


P 


44 

75 

35 

12 

74 

97 

24  3 

80 

1 

42 

5  63 

30 

23 

A 

i=VAL 

SUMS 

0 

0 

0 

0 

0 

0 

0  0 

0 

0 

'  0 

1  0  ' 

0 

„  o 

DO  J-  1  TO  1ft; 

'  IF  A(J)  *=  VAL  THEN 
DO; 


SUMS(J)  =  SUMS(J)  +  1; 
/  RETURN; 

'  END;  /  ,  '  / 

END;  '  X 


(ENTRY  2  OF  LOOP  ) 
LOOP  ITERATES  15  TIMES 


VAL 

1 10  MATCH 
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NO. MATCH  =  NO-MATCH  4.  1; _ 
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END; 


PROCEDURE  RECORD  RETURNS 


figure  4-3b 


*  SP/K  VERSION  0.4  * 
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/*  QUICK  S  OPm  PROGRAM  FOP  ILLUSTRATION  */ 
QUICKSOFT :PFOCEPURE  OPTIONS ( MAIN) ; 

DECLAP  E(A  (20) )  FIYFD; 

DFCLARr(LOWFP ( 10)  , UPPER  ( 1 0) ) FIXED ; 
r»ECLARE(N,M,L,U,X,T)  FIXED; 

SWAP: PPOCEPUPF  (X,Y)  ; 

/*  SWAPS  V*  Ln FS  A(X),  A  ( Y )  */ 

DECLARE  (X, Y,T)  FIXED; 

T=A  (X)  ; 

A<X)=A(Y);  1 

A  ( Y)  =T ; 

END; 

PARTITION; PROCEDURE; 

/*  CHANGES  A()  ,  K  SUCH  THAT  */ 

/*  A(L:K-1)  <=  A (K)  <=  A  (K+ 1 : U )  */ 

DECLARE  (N)  FIXED; 

N=L+ 1 ; 

K=U ; 

/*NLFQK :  */ 

DO  WHILE (N<=K) ; 

IF  A  (N)  <=A  ( L)  THEN 
N=N+  1  ; 

ELSE 

DO; 

/*MOVEK :  */ 

DO  WHILE  (A  (K)  >A  (L)  )  ; 

K=  K-  f ; 

END; 

IF  N<K  THEN 
DO  ; 

CALL  SWAP  (N ,  K)  ; 

N  =  N  + 1 ; 

K=K-  1 ; 

FND ; 

END,; 

END; 

CALL  SWAP (L, K) ; 

END; 

STACK : PROCEDURE; 

/*  PUTS  A (L : K- 1 )  AND  A(K+1:U)  ON  STACKS  */ 
IF  U-K>K-L  THEN 
DO; 

M  =  M+  1 ; 

LOW E P  (M)  =  K  +  1  ; 

UPPER (M) =U; 

END; 

MfM+1  ; 

LOWFF  (M) =L ; 

UPPER (K) =K- 1 ; 

IF  U-K<=K-L  THEN 
DO; 

M  =  M  ♦  1  ; 


figure  6-1 
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so 

59 

60 
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63 


I.OWEP  (M)  =K*  1  ; 
UPPFP  (M)  =U ; 

FNP ; 

END; 

N=20; 

/♦PEA DIN;  ♦/ 

DO  1=1  TO  N; 

GET  LI  ST (A ( I) )  ; 

^ND; 

LOWER  (1)  =1  ; 

UPPER  (1) =N; 

fi=i; 

/♦ST:  */ 

DO  WHILE  ( M-»=0 )  ; 

L  =  L 0 U F F  (v)  ; 

U=UPPE P  (M)  ; 

M=M-1 ; 

IF  n=L+1  THEN 

IF  A  (L)  > A  (H)  THEN 
CALL  SWAP  (L ,  U)  ; 


64 

65  IE  U>L  +  1  THEN 

66  DO; 

67  CALL  PARTITION; 

68  CALL  STACK; 

69  END; 

70  END; 

71  END; 

72  J  DATA 

FNP  OE  COMPILATION.  772  BYTES  OF  CODE  GENERATED. 


EXECUTION  BEGINS. 


END  OF  EXECUTION.  280  BYTES  OE  DATA  AREA  USED. 

766  STMTS  EXECUTFD .  0  LINES  OUTPUT.  0 


ERRORS. 


figure  6-1  ( contd. ) 


ENTRY  1  OF  PROCEDURE  QUICKSORT 


QUICKSORT:  PROCEDURE  OPTIONE(MAIN);  _ _ 

DECIARE  (A(20))  FIXED;  . ~~  /  /  7  / 

DECURE  (LOWER(IO),  UPPER(lO))  FIXED;'  '  /  / 

(DECLARE  (N,  M.  L,  U.  K.  I)  FIXED;  /  /  /  , 

!sVAP:PROCEDURK(X.  Y);  .  .  /  / 

►'  /•  SWAPS  VALUES  OF  A(X),  A(Y)  V  /  /  / 

-  END;  •/  ./  /  /  /" 

PARTITION:PROCEDURE;  /  •'  /  ./  /" 

['  /*  CHANGES  A().  K  SUCH  THAT  ♦/  / 

|  /*  A(LK-l)  <*  A(K)<-  A(K+1;U)  V  /  /  /"  / 

V  -  •  •  /  /  /  /  /'  /  /  /  /  / 

!  END;  /  /  /  ./  /  /  / 

'STACK:  PROCEDURE;  '  ./  /  /  /  /  / 

I  /'  PUTS  A(L:K-1)  AND  A(K+1:U)  ON  STACKS  ♦/  .  , 

!/■’..  t  /  /  /  /  /  /  /  /  /  / 

[. .  end-  /; .  / . Z_.Z . Ai-Z. . - 


a!  ?????????;? 


y  _ _ ?  ?  ? _ o 


N  =  20; 

/’READ1N:  *J  _ _ 

T)0  I  =  t  TO  N;  , 
i  GET  LIST  (A(I)>;  / 
r _ END;  •• _ /_ 


(ENTRY  .  1  OF  LOOP  READIN) 

LOOP  ITERATES  20  TIMES 

At  Si  “37  '  06  ~~37~  6*  »  ~S\ — 3f~76'  '  11  1}  -  37--  ■  ;t  yr  -jj  1}  ,j"  16 


LGWER(l)  =  1; 

UPPER(l)  =  N; 

M  -  l; 

/"ST:  »/  _  _ 

■DO  WHILE  (Mn=  0); 

;  '  L  =  LOWT.RfM);  ,  '  /" 

f  U  =  UPPEP.(M);  /' 
j  M  =  M  -  1;  ■  /  / 

f  LP  U  =  L  +  1  THEN 
|  /  IF  A(L)  >  A(U)  THEN,  / 
.  CALL  SWAP(L,  U};  / 

I  IF  U  ?  L  +  1  THEN 

;  DO; 

.  CALL  PARTITION; 

1  CALL  STACK;  /  / 

1  /  -END;  /"  /  /  / 

__  _  END; _ _ /  .  _ .."1. 


(ENTRY  1  OF  LOOP  Sf) 

LOOP  ITERATES  23  TIMES  _ 

.r  '  in  n  13  13  7*  2i  '27  34  il. - 15 - 15 - 55 - 52 - £1 - 23 - Si 


END; 


PROCEDURE  QUICKSORT  RETURNS 


figure  6-2 


ITERATION  1  OF  ENTRY  1  OF  LOOP  ST 

QUICKSORT:  procedure  opt:ons(main);  1 

DECURE  (A(20))  FDCED;  /  /  / 

'  DECURE  {LOVrSJtf  JO).  UPPER(lO))  FIXED; 

DECURE  (N.  M.  L.  V.  K.  I)  FIXED; 

•  5VTAP:  PRCCEDUREfX,  Y): 

/*  SWAPS  VALUES  OF  A(X).  A(Y)  */ 

END;  / 

Partition,  procedure; 

/*  CHANGE3  Af),  K  SUCH  THAT  »/ 

Y'  /»  A(LX-I)  <*  A(K)<- A(K-fl:U)  */  '  /  ./ 

!/'  END,  '  ./  /  /  /  ./  /  /" 

!  .STACK:  PROCEDdRE;/  /  /  /  /  , 

1/  /'  PUTS  A(L:K+1)  AND  A(K+1:U)  ON  STACKS  ♦/  / 

■  ''  /  /  /  /  /  /  ,/  /' 

1  /  END;  '  /  /"  /  /  /  /  /  /  / 

(  N  =  20;  /  /  /  /  /  /•  /  /  / 

!  /’READIN:  */.  ./  /  /  ./ 

r  DO  1=1  TO  N;  /  /  / 

GET  UCT(A(l)); 

V  ■  END;  /  /  /  ./  /  /  ./  /" 

LGVSR(l)  =  \-/  /  /  /  .  /  /  /'  ■ 

y  UPPER  ( I )  =  N;  /  /  /  /  /  ..■•••'■  / 

I  M  =  1;  /  /  /  /  /  y  ,•••'  / 

L_1/*?T:  !/"  '  /  '  '■  •' 


DO  WHILE  (U-1=  0); 


L  -  LOWER(M); 

U  =  UPPER(M); 
M  -  M_- .1; _ 


IF  U^_  L _+_l  THEN 
fir  A(LT>  AfU)  THEN 
1  ^CALL  SWAP(U  U); 
IF'U  >L  t  1  THEN 
DO; 

CALL  PARTITION; 


CALL  STACK; 


END, 


END. 

END.' 
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( ENTRY  1  OF  PROCEDURE  PARTITION) 
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{ENTRY  1  OF  PROCEDURE  STACK) 
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figure  6-3 


ENTRY  1  OF  PROCEDURE  PARTITION 


PAKTITIONrPKOCEDURE: 

/*  CHANCES  A().  K  SUCH  THAT  */ 
J*  A(L  K-l)  <-  A(K)<-  A(K+1:U)  */ 
DECLARE  (N)  FIXED; 


A [  55  27  8B  37  »♦  *2  H  25  U  ii  I?  i)  5?  2*  13  i* _ H  4j  1 0  3~l 


N  -  L  +  1; 

K  =  U; 
/•NLEQK:  •/ 


Al.K  ,  27.  .IS— 3L 


k::b:'„34 74  ^i3 


DO  WHILE  (N<=  K); 

•  IF  A(N)  =  A(L)  THEN 
:  N  *  N  +  1; 

'  /  ELSE 
DO. 

'  /  /‘MQVEK:  •/ 

DO  WHILE  (A(K)  *>A(L));  , 

K  =  K  -  l  :  / 

1  '  .  •••  END; 

j  .  ✓  IF  N  <  K  THEN  ,/  ' 

I-  '  DO;  /  / 

.  CALL  SWAP(N.  K);  /' 

,  '  ./  N  =  N  +  l; 

;  /  /  ,-K  *=  K  -  1;  /•'  /- 
j  /  /  /  END;  /  /  /  - 

f  END;  ''  .  '  /  / 

!  -'END:  ,/  /  / 


r  / 


GENTRY  1  OF  LOOP  NLEQK) 
LOOP  ITERATES  13  TIMES 
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*1  ft  '17  3  37  16  '  4i 
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CALL  SWAP(L,  K); 


(ENTRY  6  OF  PROP  ECU  RE  SWAP) . . 

D 

Al  17  3  SIZE  35  S  a=g  3£Z3T=gZ3I 


0 

S  ~IT~  M — 75 — 51 


E) 


n  aa  i 


END; 


PROCEDURE  PARTITION  RETURNS 


figure  6- 4a 


ENTRY  1 1  OF  PROCEDURE  PARTITION 


PARTITION:PROCEDURE; 

/*  CHANGES  A().  K  SUCH  THAT  */ 

/*  A(LK-l)  <=  A(K)  A(K+  t:U)  */ 
i DECLARE  (N)  FIXED;  j 


0 


0 


A  rii  V  3  37  '16'  'If  ff~  }i  ;_J  3  ~5?  ~  ~ ;  /!>  7  7>)  —■#-) 


N  -  L  +  1; 

K  =  U; 
/-NLEQK:  */ 


ap 


A I  ft  17  •  3  "37  "14  3E  34  ^  IS  SZZHUIiZIQ — SS~i.r-?,'— /j— 9r~ ZM3 


DO  WHILE  (N  <=  II); 

!/  IF  A(N)  <=  A(L)  THEN 
‘  N  =  N  +  1; 

:  /  ELSE 

f  ./  DO; '  /  /  / 

}/  /  /’MOVE K:  V 

Y  /  DO  WHILE  (A(K)  >  A(L)): 
!/  .  K  =  k  -  i; 

/  ./  END;  /  / 

j  ,,  ,  IT  N  <  K  THEN  ,/ 

[/  /  ,  DO;  / 

x  /CALL  SVUP(N.  K); . 

U  /  /  N  =  N '+•  U  V 

\  /  /  /K  -  K  -,'l;  ,/ 

[/  /  /  END;  /  / 

I  /  ,END;  /  /  /  / 


(ENTRY  6  OF  LOOP  NLEQK) 
LOOP  ITERATES  7  TIMES 
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CALL  S¥AP(L,  K); 


(ENTRY  15  OF  PROCEDURE  SWAP) 


P 


El 


P 


al  i2  -13  t~iy  10  is  a  ss  m'  ^  *  37  ft  'g  -j->  *2  n  — »a~»n 


END; 


PROCEDURE  PARTITION  RETURNS 


figure  6-4b 


f igure  6-5a 


f 


ITERATION  2  OF  ENTRY  6  OF  LOOP  NLFQK 

PARTITION:  PROCEDURE; 

•V  /*  CHANCES  A(),  K  SUCH  THAT  *>/ 

!  /*  A(L:K-l)  <=  A(K)  <=  A(K  +  1:U)  */ 

,  j  DECLARE  (N)  FIXED;  /  /"  /'  / 

f  N  *=  L l;  ,  /  /  /  /'  , 

!  .  K  =  U;  /  /  /  /  / 

r  /»NLEqK:  */_ _ , _ .  \ Z_  _ 

DO  WHiLE  (N  <=  K); 


D 

3 

a 

a 

24  13 

37  10  45  34  25  12  45  l 

2  r 

5  ?7  55  5  ’  6:  '3  9*  iJ  9d 

1  . 

T~ 

1 

>a.0j 

<  IF  A(N)  <r=  A(L)  THEN 
N  •=  N  +  1; 


□ 

El 

a 

a 

24  43 _ 3 _ 37 _ 10 _ 43 _ 34 _ 23 _ 42 _  _43  42  ..  23 _ 27 _ 33 _ 37 _ L3 _ 73 _ Si _ H _ Si 

.  1 

i 

-i— 

>^o) 

ELSE  _ _ _ _ _ _ _ 

DO;  ~  " 

1/  /'VfOVEK:  */  /  /  .... 

[  DO  WHILE  (A(K)  >  A(L));  / 

1  '  K  =  K  -  1;  .. 

r  .END;  /  /  /  ./ 

/  IF  N  <  1C  THEN  /  /' 

'  /DO;  /  /  /  / 

/"  /  CALL  SWAP(N.K); 

'''  '  /  N  =  N  +  If  /  /  / 

,  K  =  X  -  1;  ./  / 

/  /"  END;  /  /  /  /  / 

_  END;  _ 

iCALL  SWAP(L,  K);  ' 


LEND:.'". 

I 


figure  6-5b 


_  _  ITERATION  3  OF  ENTRY  6  OF  LOOP  NLEQK 

[PARTITION: PROCEDURE;  7 

ly  '  /•  CHANCES  A(),  K  SUCH  THAT  */  /  / 

/*  A(LK-l)  <=  A(K><-  A(K+1:U)  r/ 

|  /DECLARE  (N)  FIXED;  /  /  /  ,/  / 

f  N  =  L  >  1;'  /  /  /  /  /' 

!  K  =  U;  /  /  /  /  /  / 

t _ /.'NLEQK:  »/  /  /  / 


/  y 


DO  WHILE  (N  <«  K); 


IF  N  <  K  THEN 
DO; 

CALL  SWAP(N.  K); 


N  =  N  +  1; 
K  =  K  -  1; 
END; 


END: 


END; 


'CALL  SWAP(Li  K);/  , 

•END;  ' 


(H) 


0  0 


iy 

■y  37 — ns — is — n — sr~ 

~T3 - 71 - T3 - T5 - T" - S5 — V - l~  si  si 

1  7 

"1  ""  0  ‘  ~~ 

IF  A(N)  <=  A(L)  THEN 
rN  =  N  Vi;  1 

else" 

DO; 

ymOVEK:  */  __  _____ _ 

DO  WHILE  (A(K)  >  A(L));  / 

/ka'k/i:/  /"  /  ./"■ 

JBNDiZ— Z-y!.././  ' 


LOOP  ITERATES  0  TIMES 


(ENTRY  12  OF  PROCEDURE  SWAP) 


C- 


figure  6~5c 


ITERATION 


PARTITIONPROCEDURE; 

1/  /*  CHANCES  A(),  K  SUCH  THAT  */ 
f  /*  A(L  X-l)  <<=  A(K>  <-  A(K+1:U)  ?/ 
!  ./  DECLARE  (N)  FIXED;  /  ,  / 

N  «  L  +  l; 


/ 


/ 


/'K  =;  U;  / 
_/*NLEqK: 

DO  WHILE  (N  <  =  K); 


/ 


/ 


4  OF  ENTRY 


6  OF  LOOP  NLEQK 


□ 

1 

b 

a 

24  13  3  21  1 

i  4?  J2  K  TJ  IS  i 

5  37 

27  55  57  bl  ?3  94  99  99 

<=A(U  1 

? 

l 

IF  A(N)<*=  A(L)  THEN 
N  **  N  +  1; 


□ 

El 

a 

a 

24_13_ 3_ 23  Lfl  45_ 34_ 25  L2  45  L2  32_ 2 

7  55  57  62  73  9*  93  99 

1 

2 

j 

ELSE _ _ _ _ _ _ _ _ _ _ 

iDO;  “7  7~~  /  7~  /  / 

!/  /*MOVEK:  */  /  /  / 

f  j)0  WHILE  (A(K>  >  A(L));  /  / 

V  K  =  K  -  1; 

r  ,  'END;  /  /  /  / 

|  IF  N  <  K  THEN 

f"  •  '  DO;  '  /  /  / 

j  , '  CALL  5WAP(N,  K); 

N  =  N  +  I;  '  /" 

|  K  =  K  -  1;  / 

■r  '  END;  ,  /"  /  / 

_  END;/  ,/  / 

__  END;  ’  "  ~~ 

CALL  SVA?(L,K); 

'END;  ,  •  / _ /_ 


figure  6-5d 


PARTITION:FUOCKDURE: 

1/  /•  CHANCES  A(),  K  SUCH  THAT  V  / 
[  /*  A(L;K-  1)  <=  A(K)<-  a(K4-1:U) 

I  -  DECLARE  (N)  FIXED;  -  '  / 


ITERATION 


/ 


i  N  «  L  +  li 
/K  =■  U;  /  X  X 

/'NLEQK:  */_  /"  _ 
DO  WHILE  (N  <=>  K); 


L 


X  X 


5  OF  ENTRY 


6  OF  LOOP  NLL'QK 


□ 

El 

g 

a 

24  13  3  23  10  45  34  23  12  45  1 

j  57  77  5-i  rrt  si  7s  r*  sn 
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-Ain  n 

IF  A(N)  <  ^_A(L)_THEN 
fN  **"N  V  1;  /  | 

ELSE 
DO: 


/mOVEK:  »/ _ 

DO  V/HILE  (A(KTTA(L)]r 

LPND;/ _ / 


/ 


LOOP  ITERATES 


0  r/A/f  5 


IF  N  <  K  THEN 
DO; 

CALL  SWAP(N,  K); 


N  =  N  +  1; 
K  =  K  -  1; 
END; 


(ENTRY  13  OF  PROCEDURE  SWAP) 


END; 

END;  _  _ 

CALL  S¥AP(L.  K);  ' 
END;  /  / 


figure  6-5  e 


PARTITION  PROCEDURE: 


_ ITERATION  6  OF  ENTRY  6  OF  LOON  NU'QK 

/  /  / 

/  /•  CHANGES  A(),  K  SUCH  THAT  .♦/  /  / 

/»  A(LK-l)  <=»  A(K>  <-  a(K  +  1:U)  .»/  / 

.'nm  Anr  Im\  (TTYrn-  /  /  / 


.  DECLARE  (N)  FIXED; 

N  -  L  ♦  U  /  /  / 

/  K  =  H;  /  /  /  / 

_/'NLE(}K:  */  /  _/  / 

DO  WHILE  (N  <  =  K); 


./  ./  / 


r i 
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m — n  3  53  nr^ 

12  34  25  12  4 

5  45  37 

27  55  57  62  7d  94  »d  »3 
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nz 
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i 

_ 

IF  AjNj  <*  A[L)  THEN 

{nj-'n  *>./.  .1 

ELSE 


DO; 


/*MOVEK:  */ 

,DO  WHILE  (A(K)  >  A(L)): 
/  K  »K  r  1;  /  /' 


endl 


-(ENTRY  3  OF  LOOP  MOVER) 
LOOP  ITERATES  1  TIMES 
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IF  N  <  K  THEN 
DO; 

CALL  SWAP(N.  K); 

(ENTRY  14  OF  PROCEDURE  SWAP) 


D 
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3 

a 
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N  =  N  +  1; 
K  =  K  -  1; 
END; 


24  13  3  ii  1ft  I  i  12  2S  M  45  Vi  37  2>  55  57  52  75  91  95  ST 

.  <-*?u  i  ?  i  ; >*ip  


END; 

END;  _ 
rCALL  SWAPfu  K5T 
:END, 


figure  6-5f 


PARTITION  PROCEDURE: 

/•  CHANCES  A(),  K  SUCH  THAT  */  , 

/'  Afl.  K-1)  <=  AOO  <=  A(K+-1:U)  */ 
DECLARE  (N)  FIXED; 
f  N  =  L  +•  1;  /  .  /' 

;  K  =  V;  / 

... .  /'NLECjK:  */  ... . -i 

DO  WHILE  (N  O  K); 


ITERATION  1  OF  ENTRY  6  OF  LOOP  NLEQIC 


Af  »*■  »  3  45  <s  3' 


IF  A{NJ  <-  A(L)  THEN 
[N  ->  +  _li^U 
ELSE 


DO; 

./•MQVEK:  */ 

DO  WHILE  (A(K) 
K  =  K  -  1; 


1ENTRY  +  OF  LOOP  MOVER) 
LOOP  ITERATES  1  TIMES 


END; 

CALL  S'«TAP(L  K); 
END;_  ■  •  _  _ 


figure  6-5g 


ENTRY  1  OF  PROCEDURE  STACK 


STACK:  PROCEDURE; 

/*  PUTS  A(L:K— 1)  AND  A(K+1:U)  ON  STACKS  */ 


IF  U  -  K  >  K_-_L_THEN _ 

DO;  -■ 

M  *  M  +  1;  /  ,■ 

■  LOWER(M)  *  K  +  1; 

UPPER(M)  =  U; 

;  END;  _  / 

M  =  M  +  1; 

LOWER(M)  =  L; 

UPPEP.(M)  =  K  —  1; 
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P 
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37~~')5~  ~45~"  32 — 55 — rr 


HE 


T5 - 53 — 77“ 


0 


~57  5b  7b  t:  ~9t 


E3 


IFU-K<=K-L  THEN 
DO; 

M  «=  M  +  1; 
LOWER(M)  =  K  +  1; 
UPPER(M)  =  U; 

END; 


END; 


0 


upper  r~n~  ii  y  i  'i  ? 


j-  .  ?.  i 
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S 
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PROCEDURE  STACK  RETURNS 


figure  6-6 


at********************************************************************* 

♦  5P/K  VERSION  0.4  ♦ 

*  * 

*  * 

♦♦♦♦♦♦♦at************************************************************** 


1 

2 

3 

a 

5 


6 

7 


8 

9 

10 

11 
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27 

28 

29 

30 

31 

32 


?  :  PPOCFPHRF  OPTIONS (MAIN) ; 

DECLAF  E  (MFM  («0)  ,FPEF_LTST_HPAP,  MEM0RY_5PACE_A VAIL ABLE)  FIXED; 

FFFE  PIFCE rPPDCFDUF E (NEW_START,  NPW_LENGTH) 

DEC  LAP  F  (NFW_START,  NEW^LENGTH)  FIXED; 

DECLARE  (LENGTH  ,NEXT,  P?EF_ POINT E°)  PIXED; 

/*  STF  r  1  */ 

/*  APT  NEW  PIECF  nn  LIST,  t PAVING  CORRECT  LINKS  ON  LpFT  S  T p "  */ 
IF  ERF E_LI  S T  H  EAD>NEW_ START  THEN 
DO; 

/*  NFW  PIECF  IS  TO  LEFT  OF  FIRST  PIECE  IN  FREE  LIST  */ 

/*  APD  NEW  PIECF  TO  BEGINNING  OF  FREE  LIST  */ 

NFXT=FREE_LI ST_HEAD; 

HEM ( NFW_STAPT)  =NEXT ; 

HEM ( NEW  STAPT+1) =NFW_LENGTH; 

FREE _LIST_HFAP=NEW_S TART; 

FREE ~POINTER=NEW_ST ART ; 

END;" 

ELSE 

DO; 

/*  NEW  PIECE  IS  BETWEEN  2  PIECES  IN  FREE  LIST,  */ 

/*  OF  AFTER  LAST  PIECE  IN  FREE  LIST  */ 

/*  LOCATE  THESE  2  PIECES  OR  LAST  PIECE  */ 

FREE_POI NTEP  =  FR  EE_LI ST_HEAD ; 

NFXT=  M  EM  (FRFE_POINTER) 7 

DO  WHILE  (NEX T<NE W  START&NEXT-«=0)  ; 

FRF E_POINTER= NEXT; 

N  FXT=  MFM (FREF_POINTER)  ; 

END; 

/*  FRFF_POIN  TER  <  NEW  START  <  NEXT  */ 

/*  OP  FREF_POINT  ER  <  NEW_STAP.T  S  NEXT=0  */ 

LENGTH=M  EM  (FREE_POINTER+ 1 )  ; 

IF  FPFE_POINTFR+ LENGTH  =  N  EW_ START  THEN 

/*  MEMORY  TO  THE  LEFT  OF  NE W_ST AR  T  IS  FREE  */ 

/*  MERGE  THE  2  PIECES  */ 

MFM  (FREE  POINTER-*- 1)  =MEM  (FREE  POINTER*  1 )  +N  EW  LENGTH; 
ELSF 
DO  ; 

/*  MEMORY  TO  LEFT  OF  NFW_ST ART  IS  IN  USE  */ 

/*  MAKE  NEW  LINKS  FOR  NEW  PIECE  */ 

MEM  (NFW_START)  =NEXT ; 

MEM  (N^W^STAPT*- 1)  =NEW_LENGTH; 

MEM (FRFE_POINTER)  =NEW_STAR  T ; 

FPEE_POINTER=NEW  START; 

END;"* 

FND ; 

/*  STEP  2  */ 

/*  ALL  LINKS  IN  FFFE  LIST  ARE  CORRECT  */ 

/*  FRPF_POTNTFR  POINTS  TO  */ 

/*  PIECE  CONTAINING  (DR  =)  NFW  FREE  PIECE  */ 

/*  NFXT  POINTS  TO  */ 

/*  FIRST  FREE  PIFCF  TO  RIGHT  OF  FREE  POINTER,  */ 

/*  OR  TO  ZERO  */ 

figure  8-1 


/*  MET  GF  ON  RIGir  TF  N  EOESS  ARY  */ 

31  LF  NGTIf  =  MEM  (FREE_POINTEP+  1)  ; 

34  IF  FFFF  POI NTER+LFNGTH=NFXT  THEN 

35  DO; 

35  MEM  (FFF^POT'TTEP)  =HFH  (NEXT)  ; 

37  MFM  (FPFF~POINTFF  +  1)  =  LEMGT.h+MEM  (NFXT*1)  ; 

3  R  END; 

39  MF  MOPY  _SPA.CF_AV  AIL  ABLE=MEMO  RY_S  PACE_  A.V  AI  LA.BLE  +  N  FW_  LENGTH  ; 

40  END; 

/*  MAKE  A  FPEF  LIST  */ 

41  FPEE_LIST_HEAP=21 ; 

42  MEM  (21) =51 ; 

43  MEM  (22)  =10; 

4  4  MEM  (FI)  =  0; 

4 c>  MEM  (c?)  =1  P; 

45  MEMORY  STAGE  A V.M  IP BL F= 20 ; 

/*  FRFE  LTST~CONSISTS  OF  2  PIEGES:  (21:30)  AND  (51:50)  */. 

/*  ADD  4  TIFGES  TO  FP EE  LIST  */ 

47  GALL  FPFF_PIEGF ( 1 , 10)  ; 

43  GALL  FPEF_PIECE (7 1 , 10)  ; 

49  CALL  FREF~PIECF (6 1 , 10)  ; 

50  CALL  FPEF_PIECE (36, 5)  ; 

51  END; 

52  SDATA 

END  OF  COMPILATION.  696  BYTES  OF  CODE  GENERATED. 

EXECUTION'  BEGINS. 


END  OF  EXECUTION.  396  BYTES  OF  DATA  AREA  USED. 

91  STMTS  EXECUTED.  0  LINES  OUTPUT.  0  ERRORS. 

j 


figure  8-1  (contd.) 


z'i'TRY  l  or  PROCEDURE  FREEJFIVCE 
FP.Er.PIECE:PK0CEDUKKfNi:V/_;jTAHT.NE1H  LENGTH); 

.  DECLARE(NEVLSTART,N E7/_  IJSN GTH )  FI  X KD ;  '  7  *'7  7  7r . ~  7  7 . 

DECURE(LENGTH.NEXT,FRRE_PO!NTKR)FIXED;  /  /  /  / 

V*  STEP  1  */ 

l*  ADD  NETW  PIECE  TC  LIST,  LEAVING  CORRECT  LINKS  ON  LEFT  SIDE  ♦/ 


IF  FRZE.LIST_HEAD>NE7L  START  THEN 
DO; 

/«  NEW  PIECE  IS  TO  LEFT  OF  FIRST  PIECE  IN  FREE  LIST  •/ 
/•  ADD  NEV  PIECE  TO  BEGINNING  CF  FREE  LIST  */ 
NZXT=FREE_LIST_HEAD; 
i!Z  i!  (  XEV*_ST  ART , = NEXT; 

MZM,'NTW_START-s- 1  }=NEVLIJ3NGTH; 

FP.EE_LIST_HEAD = N  EV, ’.START; 

FR  E ILFOINT  £R  -  NE  VLSTART ; 

END; 


FREE.UST  HEAD 1 

NEW. START  j|  FREE  JOINTER  1 

NEXiJ 

_ 1  _ . 

FIRST  |  ! 

ELSE 


DQi  /  7  •"  7  ''  7  /  7 

/  /*  NEW.  PIECE  IS  BETWEEN  2  PIECES  IN  FREE  LIST,  7/ 
/  OR  AFTER  LAST  P^ECE  IN  FREE  LIST,*/  ,7 
7/*  LOCATE  THESE  2  PIECES  OR  LAST  PIECE'  *//  / 

FREE.POINTER=FREELLISTJTEAD;  /'  ./'  / 

./  NEXT  =  MEMfF REE.POIN  TER ) ;  /'  /  /"  .7 

•'  DO  WHILES NEXT-cNE  W_START&NEXTS  =0);  .7 

7  FREE_POINTER=NEXT;  7"  7  7'  ,7  ,7 

NEX7=MEM{FREE_F0INTER);  / 

7  END;  7  .7  .7  7"  7  / 

/*  FREELPOINTER  <  NEWJ5TART  <  NEXT  '/  /" 

/*  OR  FR2ELP0INTER  <  NTT-LST ART  &  N£a7*0  *// 

'  I£NGTK=MEM(FRE£JPOIi\TER  + 1);' 

JF  FREE-POINTER-rLENGTII=NEILSTART,TilEN  __ 


/ 


/*  MEMORY  TO  THE  LEFT  CF  NET*’  .STAR?  IS  FREE  */  .7  ' 

/ /*  MERGE  THE  2  PIECES  7"  /  7  7  ...7  /"  7" 

/  MEM(FREEJ,01NTER+l)=MEM(FREE^POINTER+i)+NEWa£NGTH;  7 
''  ELSE  7  7"  7  .7  /'  7"  7'  7 

7  DO;  7  7  /  7  .7  ./  7  /  /  /  7 

7  /*  MEMORY  TO  LEFT  OF  NE’A’.StART  IS  IN'' USE  */  '  /  / 

7  /»  MAKS  NEn  LINKS  FOR  NEW  PIECE  */  7  /'  /  /  .7 

/  mem<:ne;v_start)=next;  7"  /  7" 

7  MEM{NTVCSTA_RT-rl)=NEPU,ENGTK:''  /'  /'  7  ./"  7'./' 

ME  M(  FREE_POINTE  R) = NEWLSTART;  /'  .7  7  ,7  .7 

FREEJ>01NTER=  NEW.J5TART;  7'  7'  7  /"'  /"  7  .7  /' 

END;  ,  7  7  7  /  /'  /  7"  /'  , 


/' 


END; 
STEP  2 


'/ 


/ 

/* 


/*  ALL  LINKS  IN  FREE  LIST  ARE  CORRECT 
/•  FREE  POINTER  POINTS  TO  */ 

/•  PIECE  CONTAINING  TOR  =)  NEW  FREE  PIECE  »/ 

/*  NEXT  POINTS  10  */ 

'♦  FIRST  FREE  PIECE  TO  RIGHT  OF  FREE.POINTER,  */ 

OR  TO  ZERO  V 

MERGE  ON  RIGHT  IF  NECESSARY  */ 

LENGTH  =MEM(FREE_POINTER+ 1 ); 

IF  FREE.P01NTER -f  LENGTH  =  NEXT  THEN 

DO.  "  71  "’T 

. MSiI(FREE  JOINTER)  =MEM(NEXT);/  7  /'  / 

i{IM(FRE2L?0INTER+i)  =  LENGTH+MEM(NEXTTl); 

'7  END:  _  -  .7 _ 7  ,7  7  _  , 

memory_space7vailable=mem6ry_'spacejivajlable+new_length; 

END; 

PROCEDURE  FREE_P1ECE  RETURNS 


I 

! 

I 


figure  0-2 


ENTRY  1  OF  PROCEDURE  FREE.PIECE 
FREK_PIKCE:PHOCEDUi?K(NKW_iJTAKT,NKW..  LENGTH); 

ibEfnARB(NEVrj5TART.HEWJJiNGTH)KIXKD;  ,  . 7"'"7'"  "7" . Y~ 

,DECLARE(LENGTf11NEXT1FREE_P0INTKR)FIXED;  ,  , /  / 

;/•  STEP  1  */ 

■  /»  ADD  NEW  PIECE  TO  LIST.  LEAVING  CORRECT  LINKS  ON  LEFT  SIDE  */ 


MEM  [ 


NiEPl|NEW_sWnrFREE-UST_HEADl 


FREE 


IF  FREE  _LIST_HEAD>NEW_ST ART  THEN 
DO: 

/«  NEW  PIECE  IS  TO  LEFT  OF  FIRST  PIECE  IN  FREE  LIST  */ 
/*  ADD  NEW  PIECE  TO  BEGINNING  OF  FREE  LIST  */ 
NEXT=FREE_LrST_HEAD; 

MEMf  NEW.iTT  ART )  =  NEXT; 

MEM(NEW_START  4- 1 ) = NEWJJCNGTH; 

FRF.E_LIST_JIEAD  =  NEVYJ3TAKT; 

FREE_POINTER-NEW_  START; 

END; 


FREE UST HLAD| 

NEW STAHI: 

FREEL-POINTER  ||  NEXT  1 

-  1 - 

FREE  1  1 

FREE 

ELSE 
I  DO; 


I 


7 


7 


/*  NEW  PIECE  IS  BETWEEN  2  PIECES  IN  FREE  LIST, 

/«  OR  AFTER  LAST  PJECE  IN  FREE  LIST  */ 

/*  LOCATE  THESE  2  PIECES  OR  LAST  PIECE 
FF:EE_P0INTKR=FREE_L1ST_HEAD; 

NEXT=MEMf  FREE.  POINTER); 

DO  VTHILE( NEXT<NEW  START&NEXTn=0);  /" 

FREE_POINTER=NEXT; 

NEXT=MEM(FREE_POINTER);  /  /  /"  /  /" 

END;  /  /" 

/*  FREELPOINTER  <  NEW.  START- <  NEXT  */" 

/«  OR  FREEL-POINTER  c  NEW  START  &  NEXT=0  */  ./" 

LENGTH*  MEM(FP.EE_POINTER+ 1);-"  /•  /  /  / 

IF  FREE_POINTER+I£NGTH*NEW_START  THEN- _ 

/*  MEMORY  TO  THE  LEFT  OF  NSWJ3TART  IS  FREE  >/  /"  / 

/*  MERGE  THE  2  PIECES  */  .7  / 

MEM(FREE_FOINTER+ 1 )  =MEM(fREE_PO'INTER+1)+NEVLLENGTH; 
ELSE  ■  /  ■  ,/  /  /  /"  / 

DO;  /  /'  /  /''  /  / 

/"  MEMORY  TO  LEFT  OF  NEVLSTART  IS  IN  USE  V,  /" 

/*  MAKE  NEW  LINKS  FOR  NEW  PIECE  ?/  /  ./  /  /" 

/  ME  M(  NEW-START ) = N  EXT,  /  /'  /  /  , 

M  E  M(  N  E W_START  +  l )  =NE  W_DENGTH;  /  ./  /"•  /  /" 
/  MEM(FREE_POINTER)=NEVLSTART;  /  /'  ,/"  ./ 

FREEJ>0|NTER=NEW_START;  ,  7  /  7  / 

'  7  END;  7  7  /  /'  / 


END; 
STEP  2 


/  / 


7~ 


7 


/* 

/*  ALL  LINKS  IN  FREE  LIST  ARE  CORRECT 
/*  FREE_P01NTF,P.  POINTS  TO  »/ 

/•  PIECE  CONTAINING  (OR  =)  NEW  FREE  PIECE  */ 

/•  NEXT  POINTS  TO  V 

/*  FIRST  FREE  PIECE  TO  RIGHT  OF  FREE_FOINTER. 

/»  OR  TO  7.ERO  V 
/*  MERGE  ON  RIGHT  IF  NECESSARY  V 
LENGTH  =MEM(FREE_POINTER+l); 

IF  FREE_PGINTER+LENGTH=NEXT  THEN  _ 

DO,  "  /  / 

MEM(FREE_POiNTER)=MEM(NEXT); 

I  VfEW(FREE_P01NrrER+l)  =  LENGTH  +  MEM(NEXT+l); 

'  END; 

MEm6rY.SPACE_AVAILADLE=MEm6rY_SPACELAVAILABLE+  NEW_  LENGTH; 

END; 

PROCEDURE  FREE-P1ECE  RETURNS 


figure  0-3a 


ENTRY  2  OF  PROCEDURE  FREE. PIECE 
FREE  PIFXE:PROCEDURE(Ni;W_.TrART.NKW_LENGTH); 

DECLARE(NEVU5TART,NEW_LKNGTH)FIXKD;  '  '  "•r"/  -•7--  pr~-;r . ^ 

!OECI^E(LENGTH.NEXT.KIiEK.POlNTBR)KIXED;. 
f/*  STEP  I*/ 

!/'  ADD  NEW  PIECE  TO  LIST.  LEAVING  CORRECT  LINKS  ON  LEFT  SIDE  ♦/ 


IF  FREE_USTJIEAD>NEW_START  THEN 
fDO.  '  /  ••••'  /- 

,  /«  NEW  PIECE  IS  TO  LEFT  OF  FIRST  PIECE  IN  FREE  LIST  */ 

/*  ADD  NEW  PIECE  TO  BEGINNING  OF  FREE  LIST  */  /  ./ 

/  NEKT=FREE_LIST_HEAD; 

'  MEM( NEWJsT ART) -  NEXT;  / 

I  ,  MEM(NEW_START-»- 1 J-NEVC IJSNCTH; 
f  FREE  J.ISTJIEAD*=NEVV_ST  ART; 

■  FREE  J'OINTER^NEW.ST  ART; 

END;  • _  /  /  /  ./ _ /_ 

ELSE  '  . 7“ 

DO; 

/*  NEW  PIECE  IS  BETWEEN  2  PIECES  IN  FREE  LIST,  */ 

/*  OR  AFTER  LAST  PIECE  IN  FREE  LIST  */ 

/-  LOCATE  THESE  2  PIECES  OR  LAST  PIECE  */ 
FREE_POINTER=FRF.E_LlST_HEAD; 

NEXT=MEM(FP.EE_POINTER); 


MEM I  FREE 


DO  H’HltE(NEXT<NEW.START&NEXf-i=Q);  / 

[  '/  FREE_POINTER=NEXT;  /  / 

NEXT*MEM(FP.EE_POINTER); 

!  /enD'  / 

-•  -  "  {ENTRY~~'\‘OF  loop  ) 

 LOOP  ITERATES  2  TIMES 


NEXT| 

FREE LI5T HEAD  I 

FREE.  POINTER  1 

NEW STAR1 | 

y 

FREE 

L 

FREE  1  1 

NEW 

NEW.START 


NEtV 


R£E POINTER]|NEXT  i 


FREE 


/*  FREE_POINTER  <  NEW_  START  <  NEXT  */ 

/*  OR  FREE_POINTER  <  NEW  START  &  NEXT=0  */ 
LENGTH=UEM(FREE_POINTER-t-l);  . 

IF  FREEJ3OINTER+LENGTH=NEW_START  THEN 

/♦  MEMORY  TO  THE  LEFT  OF  NEVLSTART  IS  FREE  */ 

h  MERGE  THE  2  PIECES  */  _ _ 

(MEM(FREE_POINTER+ 1 ) = M  K  M  ( FRE  E_  PO  INTER +  lT+ NEWLlENCTH;  "  ~7~1 
ELSE 
DO; 

/*  MEMORY  TO  LEFT  OF  NEVLSTART  IS  DT  USE  */ 

/*  MAKE  NEW  LINKS  FOR  NEW  PIECE  */ 

MEM(NEW_START)=NEXT; 

MEM(NEYLSTART+  1)=NEW_LENGTH; 

MEM(FREE_POINTEK)  =  NEW_START; 

FREE_POINTER=NEW_START; 

END; 


NEXT  il  FREE LIST HEAD| 

1  NEW  START  | 

FREE POIN~IER| 

r  L— 

FREE 

3  EF^IZ] 

END; 


figure  0-3b 


/*  step  2  •/ 

/»  A1.L  LINKS  IN  FREE  LIST  ARE  CORRECT  »/ 

/*  FRLEJ’OINTER  POINTS  TO  */ 

/*  PIECE  CONTAINING  (OR  -)  HEW  FREE  PIECE  */ 

/»  NEXT  POINTS  TO  ’/ 

/*  FIRST  FREE  PIECE  TO  RIGHT  OF  FREE_POINTER,  */ 

/»  OR  TO  ZERO  */ 

/*  MERGE  ON  RIGHT  IF  NECESSARY  «/ 

LENGTH  =  MEM(EREE_POINTEK  +  l ); 

IF  FRL'E_POINTEP.  + LENGTH -NEXT  THEN 
DO. 

ME«(FP.EE_PCINTER)  =  MEMfNEXT); 

VfElI(FREE_POINTER+l)  =  LENGTH+MEM(NEXT+l); 

..  END; . . ... _ __ _ . .  . .  . , 

MEMORY_SPACE_AVAJLABLE  =  memory_spacelavailable+  NEW_LENGTH ; 

END; 

PROCEDURE  FREE-P1ECE  RETURNS 


figure  8-3b  (contd.) 


ENTRY  3  OF  PROCEDURE  FHEEJ’JtX'E 
n?rr_P!rcn.PROCEr>uiii:(Mr.v;_rrrAi{T.NKYM.F;NGTiij; 

D2CURE(NEW_START.HKW.U-:NGTH)riXED;  .  '  7"~  7 

D£CIARE(LENGTH.NEXT.m:K  J>OINTKie)KIXi:D;  ' 

7*  STEP  1  »/ 

/»  ADD  NEW  PIECE  TO  LIST.  LEAVING  CORRECT  LINKS  ON  LEFT  SIDE  ♦/ 


piExrl 


FPEEJ'OIMlfP1|FREE-LI5T-HEADl 


MEM 


FREE 


N[J3Wfi] 

l~NEW  r 


IF  FREE_LIST_HEAD>NEW_START  THEN  _ _ _ _ 

;  DO:  7  /  7  7  7*-  • 

.  /*  NEW.  PIECE  IS  TO  IJCFT  OF  FIRST  PIECE  IN  FREE  LIST  */ 

[  /«  ADD  NEW  PIECE  TO  BEGINNING  OF  FREE  LIST  */ 

!  7  NEXT = FREE  J.lST_J-rEAD; '  /'  .7 

\  11 E M ( NEW_STAHT )  -  NEXT; 

i  -  MEM(NEiV_START  H)  =  NKW_LENGTH; 

•  FREE_LI3T.  HEAD --=NEW_  START;  i 

.  FREE  POINTER- NEWEST  ART; 

END  • _ _  •-■■■_  7  1  _7 _ 7  7_  <1 _ , _ /_  _  ,  ] 

ELSE 

DO; 

/*  NEW  PIECE  IS  BETVIEEN  2  PIECES  IN  FREE  LIST,  */ 

/*  OR  AFTER  LAST  PIECE  IN  FREE  LIST  ' / 

/*  LOCATE  THESE  2  PIECES  OR  LAST  PIECE  */ 
FREE_POINTER=FREE_LIST_HEAD; 

NEXT=MEM(FREE_POINTER); 


FREE-LIST-HEAD 

FREE.POINTERI 

NEXT 

NEW.STARTI 

I  , 

r 

I  DO  WHILE(NEXt<NEW^Sf  ART&NEXfL«=0}'i  .7 

I  7  FREE_P01NTER=NE)CT; 

\  NEXT='MEM(FP.EE_POINTER);  / 

!  END:'  7 

(ENTRY  ~  2  OF  LOOP  ) 

_ LOOP  ITERATES  2  m/ES_ 


T 

x 


FREE-LIST_HEAD| 

FREE-POINTER 

NEW-START  | 

NEXT  | 

y 

r 

fREE  |  ~ 

L 

FREE 

NEW 

FREE 

/*  FREE-POINTER  <  NEVL START  <  NEXT  */ 

/*  OR  FREE-POINTER  <  NEYilSTART  &  NEXT=0  */ 

LENGTH  =  MEM^FRKE  -POINTER -I- 1 );  , 

IF  FREE_POINTER+LENGTH=NEW_START  THEN 

/*  MEMORY  TO  THE  LEFT  OF  NEVL  START  IS  FREE  ♦/ 

/*  MERGE  THE  2  PIECES  */ 

MEM(FREE_POINTER+1)=MEM(FREE_POINTER+1)-fNEWLLENGTH; 


FREE LIST HEAD| 

FREE.POINrERl 

NEW  .-START! 

NEXT  | 

1 

■  1  1 

FREE 

FREE 

ELSE 

•DO;  "  7"  ~y . ’7  7  7  .7  Z~' 

i,-  /»  MEMORY  TO  LEFT  OF  NEW  START  IS  IN  USE  »/ 
f  /*  MALE  NEW  LINKS  FOR  NEW  PIECE  */  .7  7 

I .  MEM( NEW. START) = NEXT;  .7  .7 

I  MEM(NKW-START+  1)=NEW_LENGTH; ,  7  7  7"  / 

i  MLM(EREE.POINTER)~NEW_  START;  7  /'  7 

f  FKEE.POINTER=NEW_ START;  ,  '  7  7  7" 

i  END:  7'  7  ,7  .7  7  7  ,7 

END,  . 


f igurc  8-3c 


/*  STEP  2  */ 

/•  ALL  LINKS  IN  FREE  LIST  ARE  CORRECT  */ 

/*  FREE. POINTER  POINTS'  TO  »/ 

/*  PIECE  CONTAINING  (OR  -)  NEW  FREE  PIECE  ♦/ 

/•  NEXT  POINTS  TO  V 

/*  FIRST  FREE  PIECE  TO  RIGHT  OF  FREE_POINTER,  */ 

/»  OR  TO  7.EP.0  V 

/*  MERGE  ON  RIGHT  IF  NECESSARY  */ 

LENGTH  =  MEM(FREE_POINTLR+ 1 ); 

IF  FREE.POINTER+LENGTH=NEXT  THEN 
DO. 

iIEM(FP£E.POINTER)-MEM(NEXT); 
MEM(FREE_PCINTER+ 1  )  =  LENGTH+MEM(NEXT+  1); 
END; 


FREtZJJSr-HEADl 

FREE POINILRi 

NEW_SlAKf] 

next! 

( 

L 

FREE 

MEM0RY_SPACE_AVAILABLE=MEM0RY_SPACE_AVAILABLE4NEW_LENGTH; 

END. 

PROCEDURE  FREE. PIECE  RETURNS 


figure  8-3c  (contd.) 


ENTRY  4  OF  PROOF  DURE  FRFFJP1FCE 
FREK.PIECE  :!*l«)CHn)KKfNKW_STAirriNKW.I.KNGTH); 

bECURK(NE»LSTART.NEW.I4KNGTH)KIXKD;  '  V . 7" 

DECIARE(LKNGTn.NEXT.FREE_POINTKK)FD(ED; 

:/•  STEP  1  •/ 

[•  ADD  NEW  PIECE  TO  LIST,  LEAVING  CORRECT  LINKS  ON  LEFT  SIDE  «/ 


poDp 

7  7 


FRLE.POIMrER| 


EREE-LI5T HEADl 


MEM  L 


FREE 


NEW-SIARfl 

I  NEW  I 


IF  FREE_LJST_HEAD>NEW_START  THEN _ _ __ _ 

i  /'  NEW  PIECE  IS  TO  LEFT  OK  FIRST  PIECE  IN  FREE, LIST  */ 
f  /*  ADD  NEW  PIECE  TO  BEGINNING  OF  FREE  LIST  */ 

I  NEXT = FRKE._L15T_HEAD; 

Mi  M  ( NEW,  ST  Ali  T ) = N  EXT; 

MEMfNEW„START+ 1  )=NEW_LENGTH; 

-  FREE  J.IST_1IEAI)=NEW_  START: 

FREKJ'OINTER- NEW_START ; 

1"  END;  •  _ 7  / 

ELSE 

DO; 

/«  NEW  PIECE  IS  BETWEEN  2  PIECES  IN  FREE  LIST,  */ 

/’  OR  AFTER  LAST  PIECE  IN  FREE  LIST  */ 

/•  LOCATE  THESE  2  PIECES  OR  LAST  PIECE  */ 
FREE_POINTER=  FREE_LI£TLHEAD; 

NEXT=MEM(FREE_POINTER); 


FREE-LISLHEADlfFREElPOINrERlfNEXT 


C 


NEW  START  I 


MEM 


FREE 


I  FREE 


NEW 


[DO  Vi'H!LE!(NEXT<;NEW_START&NEXT-'_=6);  ,/ 

!  .'•''FREE_T01NTER=NEXT; 

'  NEXT=MEM(FP.EE_POINTER);  , 

L  'END; _ _ _  _  /  /_ 

"  "  (ENTRY  3  OF  LOOP  ) 

_ LQQP^LTE RATES. _ L HUES. _ 


EREE.LIST HEAD| 

FREE.POINTERl 

NEW.START  | 

/ 

MEM  I  FREE  [  I  FREE  I  |  NEW  I  |  FREE 


/•  FREE_POINTER  <  NEW_START  <  NEXT  */ 

/*  OR  FREE_POINTER  <  NEW  START  k  NEXT=0  */ 
LENGTH=MEM(FREE_POINTER+l);.  , 

IF  FREE_P01NTER-t- LENGTH =NEW_ START  THEN 

/*  MEMORY  TO  THE  LEFT  OF  NET1LSTART  IS  FREE  */ 

/’  MERGE  THE  2  PIECES  */  _ _ r 

LMEM(FREE_POlNTER+ 1 )  =  M  EM(FREE_P0  INTER  +  iKNECLENSTH;  7  7  ] 

ELSE 


DO; 

/»  MEMORY  TO  LETT  OF  NEW_START  IS  IN  USE  ■*/ 
/*  MAKE  NEW  LINKS  FOR  NETT  PIECE  */ 

M  E  M  ( N  E  V/_  START ) = N  E  XT ; 

MEM(NEW_START+ 1)=NETT_LENGTH; 
MEM(FREE_POINTER)=NEW_START; ' 
FREE_P01NTER=NEW_START; 

END; 


EPEEJJSLHEADi 

NEW S1 ART  | 

FREE POINTERl 

NEXT  | 

™EE  1  I 

FREE  | 

1 

FREE 

END; 


figure  8-3d 


/*  STEP  2  •/ 

/*  ALE  LINKS  IN  FULL’  LIST  ARE  CORRECT  */ 

/*  FP.F.E  POINTER  POINTS  TO  »/ 

/*  PIECE  CONTAINING  (OR  =)  NEW  FREE  PIECE  ♦/ 

/'  NEXT  POINTS  TO  ♦/ 

/*  FIRST  FREE  PIECE  TO  RIGHT  OF  FREE  POINTER,  */ 

/•  OR  TO  ZERO  V 

/*  MERGE  ON  RIGHT  IF  NECESSARY  «/ 

LENGTH  =MEM(LREE.POINTLR+  1 ); 

IF  FREE_POINTEP.+ LENGTH -NEXT  THEN 

DO;  '  V  '  V . I 

MSiI(FP.EE.POINTES)=MEM(NEXT):  ! 

;  MEM(FREE_POINTER-H)=LENGTH+MEI4(NEXT+l); 

END, _ _  _ _ -  ■  '  .  ‘ 

M£MORY_SPACE_AVAILABLE  =  MEMORY_SPACE_AVAILABLE+NEW_LENCTH; 

END; 

PROCEDURE  FREE-PIECE  RETURNS 


figure  8-3d  (contd.) 


ENTRY  1  OF  PROCEDURE  FREfLPlFCK 
FREE  PIECE: PROCEDURE? NEW  ETAKT.NKW  LENGTH); 

DKC1ARK(NEW_START,NKW.  LENGTH  )FIM:i>;  '  • .  . .7  ’7  “  7 . ,  ' 

DKCUSEfLENGTlI.NEXT.FIlRE.POINTKRjKIXKD;  .7 

i/»  STEP  1  */ 

J*  ADD  NEW  PIECE  TO  LETT,  LEAVING  CORRECT  LINKS  ON  LEFT  SIDE  ♦/ 


IF  FREE- IiST_HEAD>NEW_ST  ART  THEN 
DO; 

/«  NEW  PIECE  IS  TO  LEFT  OF  FIRST  PIECE  IN  FREE  LIST  */ 
/*  ADD  NEW  PIECE  TO  BEGINNING  OF  FREE  LIST  */ 

NEXT= FREE,  U3T_H  FAD; 

MEM(  NEWJ5TAP.T)  =  NEXT; 

M2M(NEW_STARTfl)  =  NEW_LENGTH; 

FREE  _LI3T_  HEAD=NEW  START; 

FREE_POINTER=NEW.  START; 

END; 


MEM  [ 


FREELUST-HEADl 

NEW-START  ||  FREE-POINTER  | 

NEXT  | 

FREE  1  I 

"T  FREE  2  f~ 

— 1  FREE  3  | 

ELSE 
I  DO; 


/*  NEW  PIECE  IS  BETWEEN  2  PIECES  IN  FREE  LIST,  *j 
/*  OR  AFTER  LAST  PIECE  IN  FREE  LIST  »/ 

/*  LOCATE  THESE  2  PIECES  OR  LAST  PIECE'-/ 

FREE_POINTER=FREE_L!ST-HEAD; 

NEXT=MEM(FREE_pOINTER); 

DO  YTHlLE(NEXT<NEVLSTART&NEXT->=6); 

7  FREE_POINTER=NEXT;‘ 

/  NEXT=MEM(FREE_POINTER);  /  / 

7  END;  '  7  7  7  /  7 

/*  FREE-POINTER  <  NEW_START  <  NEXT  V 
/«  OR  FREE_P01NTER  <  NEWLSTART  &  NEXT-6  */ 
LENGTH=MEM(FREE_P01NTER-t-l); 

IF  FREE-POINTER+LENGTH=NEW_START  THEN  " 


./■  /*  MEMORY  TO  THE  LEFT  OF  NEW-START  IS  FREE  V 

/ /*,  MERGE  THE  2  PIECES  V  7  7  /" 

/  MEXl(FREE_POINTER+l)=MEM(FREE-POINTER+i)-fNEW_LENGTH; 

ELSE  /  7  7  7  7  /  7  7'  7 

/  P°;  7  7  ■  7  7  /  7"  7'  .  " 

7  /♦  MEMORY  TO  LEFT  OF  NEW_START  IS  IN  USE 

7  /*  MAKE  NE7f  LINKS  FOR  NEW  PIECE  */  / 

/•  MEM(NKWJ3TART)=NEXT;  <  7  /  7 

ME  M  (N  E  W-START  +  1 ) = N  EW-LEN  GTH;  /  / 

/  MEM(FREE-POINTERJ  =  NEW- START;  7 

7  FREE-POJNTER -NEW-START;  /  7  7 

7  y  END;  /  /  /  /  7  7  /  / 


7/ 


7 


/ 

/' 

/' 

/' 

/* 

/• 

/* 

/* 


END; 
STEP  2 


7 


V 


ALL  LINKS  IN  FREE  LIST  ARE  CORRECT 
FREE-POINTER  POINTS  TO  »/ 

PIECE  CONTAINING  (OR  =)  NEW  FREE  PIECE  »/ 
NEXT  POINTS  TO  */ 

FIRST  FREE  PIECE  TO  RIGHT  OF  FREE-POINTER. 
OR  TO  ZERO  4/ 

MERGE  ON  RIGHT  IF  NECESSARY  «/ 

LENGTH  ~MEM(FREE-POINTER+ 1 ); 

IF  FREF_PuINTER  fLENGTH- NEXT  THEN_ _ _  _ 

[do,  7  / 

!  MEM(FP.EE_POINTER)  =  MEM(NEXT);' 

|  MEM(FREE_POINTER+  1  )=LENGTH+MEM(NEXT+i); 

i  END;  7  ■'  _ 


MEMORY. 

END; 


3PACK-AVAI  LAB  LE  =  MEMORY_  SPACE  JTVAILABLE4NEW-LENGTH; 

PROCEDURE  FREE_PIECE  RETURNS 


figure  8-4a 


ENTRY  2  OF  PROCEDURE  ERFeIpIECE 
'  FREE  JIEC'K  PROCEDURKfNKV/.START.NFW.  LENGTH); 

DECLARK{NEW_START.NKWJJ-:NOTH)KIXED;  ”  ",  .  ’  ’ 

DECLARIWLKNCTH.NEXT.FREK  JOINTKR)FlXFD; 

/*  STEF  1  */  • 

/»  ADD  NEW  PIECE  TO  UST.  LEAVING  CORRECT  LINKS  ON  LEFT  SIDE  ♦/ 


(Tofl 

FREE  JOiMTLRl 

FREE  LIST  HEADl 

N  E  vV  START  1 

? _ j 

> _ _ _ _ ~ 

MEM  1  FREE  1  1 

1  FREE  2  1 

~1  FREE  3  T 

L 

NEW 

IF  FREE JJST. HEAD>NEW_ START  THEN  _ _ _ _ t _ _ _ _ 

DO; 

,  /*  NEW  PIECE  IS  TO  IFFT  OF  FIRST  PIFCE  IN  FREE  LIST,  */ 

/*  ADD  new  piece  to  beginning  ok  free  list  */ 

I  NEXT 13  FREE  J.I3T_iIEAI); 

,  MEM  (  NFW_STAP.T)  =  NEXT, 

.  MEM(NEV.'_STARI'4-  1)  •  NEW. LENGTH; 
r  FP.EE_LIST_HEAD=NEWL  START; 

I  FREE_POINTER=NEVL  START;  /"  /  / 

[•'  END;  ,  "  /  /  / 

ELSE 

DO; 

/♦  NEW  PIECE  IS  BETWEEN  2  PIECES  IN  FREE  LIST,  */ 

/■*  OR  AFTER  LAST  PIECE  IN  FREE  LIST  */ 

/«  LOCATE  THESE  2  PIECES  OR  UST  PIECE  */ 
FREE_POINTER  =  FREEJ,IST_HEAD; 
NEXT=MEM(FREE_POINTER); 


FREE LIST HEAD| 

FREE  JOINTER  | 

NEXT  | 

r 

MEM  f  FREE  1  |  |  FREE  2  j  |  FREE  3 


MEW SrART| 


"DC  TO  I L  E  ( N  E X T <  N  E  >V_S  T A  RT  A-.  N  E /.TS  =  6 )  f 
'  /  FREE_P01NTER=NEXT; 

[  NEXT=MEM(FP.EE  JOINTER); 

I  END.' 

" . (ENTRY 

_ LOOP 


i  OF  LOOP  ) 


NEXT  | 

FREE LI5T HEAD| 

FREE  JOINTER] 

NEW START| 

FREE  1 

1  FREE  2  f~ 

1 

FREE  3  1  I 

NEW  | 

/*  FREE  JOINTER  <  NEW_  START  ^,NEXT  */ 

/*  OR  FREEJOINTEP.  <  NEW  START  &  NEXT=0  */ 
LENGTHTOEHfFREEJOINTEK+l); 

IE  FREE  JOINT  ER+LENGTH=NEW_START  THEN 

/♦  MEMORY  TO  THE  LEFT  OF  NEYLSTART  IS  FREE  ♦/ 

7*  MERGE  THE  2  PIECES  V 

■  M  EM  ( FR  E  E  J  Q I N  T  E  R  +  1 )  =  M  E  M  (  FR  E  E  JP0 1NTE  R +1 ) +N  E  W1LEN  GT  Hi; " 
ELSE 
DO; 

/♦  MEMORY  TO  LEFT  OP  NEW_ START  IS  IN  USE  */ 

/*  MAKE  NEW  IJN IIS  FOR  NEW  PIECE  */ 

MEM  (NEW_START  J  =  N  EXT. 

MEM(NEW_START+1)=NEW_LENGTH; 

MEM(FREEJOINTER,)  =  NEW_START; 

FREE_POINTER=NEW_START; 

END; 


NEXT  | 

FRFE.LIST HEAD| 

[  NEV/_  START  ||  FREE  JOINT  E  R  | 

FREE1 1 

1  FT^EE  2  r 

— I  FREE  3  I  |  FREE  4  1 

END; 


figure  B~4b 


/*  STEP  2  */ 

/»  ALL  LINKS  IN  FREE  LIST  ARE  CORRECT  */ 

/»  FREE. POINTER  POINTS  TO  */ 

/*  PIECE  CONTAINING  (OR  •=)  NEW  FREE  PIECE  «/ 

/•  NEXT  POINTS  TO  -/ 

/*  FIRST  FREE  PIECE  TO  RIGHT  OF  FREEJPOINTER,  »/ 

/»  OR  TO  ZERO  V 

/•  MERGE  ON  RIGHT  IF  NECESSARY  •/ 

LENGTH  =  MEM(FREE_POINTER+l); 

IF  FREE -POINTER  +  LENGTH =NEXT  THEN 

DO;  . . 7 . 

MEM(FREE_POINTER)=MEM(NEXT); 

KEH(FREE_PGINTER-i-l)  =  LENCTH  +  MEM(NEXT+l); 

END;  _  . ;■ .  _ _ _____ 

MEMORY_SPACE_AVAILaBLE  =  MEMORY  SPACE-AVAIUnLE+NEW-LENGTH: 

END; 

PROCEDURE  FREE_PIECE  RETURNS 


figure  8-4b  (contd.) 


' ENTRY  3  OF  PROCEDURE ~ FREE. PIECE 


FKr.K  J’.’KCF:  PI(nCEDURK(NKW  ;n'ART,N>:w.  l.KNGTII); 
LKCL\RK(NKWj5TART.N>:W_l.i:NGIH)nXi;D; 
D-CURF:(l.KNCTfl,NR;:<T.FRPK_rOINTKI?)KrXKD; 

/»  STEP  1  »/  ' 


/•  ADD  new  piece  to  list.  leaving  correct  links  on  left  SIDE  V 
nEyTllFPLE.PQimTRllFRLE_LIST_HEADl 


MEM  1  FREE  1  ~ 


FREE  l...  1 


N£W_STAKf] 

FREE  3  1  NEW  T~~F|TeE  4  1 


IF  FREE  JJST.JI EAD>NEW_  START  THEN _ _  _  _ 

'DO.  jr  /  7  7  / 

j.  /‘  NEW  PIECE  IS  TO  LEFT  OF  FIRST  PIECE  IN  FREE  LIST  "/ 
f  /*  ADD  NEW  PIECE  TO  PFCINNING  OF  FREE  UST  *f 

NEXT-FREE. LI3T.HEAD;  /  / 

:  MEM(NEV_STAP.TJ=NEXT; 

!  MEMfNEV_STM!T4-l)-  NL’WJ.ENCTH: 

-  FP.EIU.ISTJIEAD--  NL’V_STAKT; 

FREE_POINTER  =  NEW_  START ; 

7  END;  ./  /./  7  / _ /' 

ELSE 

DO; 

/"  NEW  PIECE  IS  IJETWF.EN  2  PIECES  IN  FREE  LIST,  */ 

/*  OR  AFTER  LAST  PIECE  IN  FREE  LIST  */ 

/-  LOCATE  THESE  2  PIECES  OR  UST  PIECE  7 
FREE_POINTER=FREE_LIST_HEAD; 

NEXT=MEM(FP.EE_POINTER); 


FREE.UST HEAD| 

FREE POINTER| 

nexTI 

new_sTarT] 

r 

FREE  1  r 

I  FREE  2  I 

i  fret^  r 

NEW  !  FREE  4 

D  OWH I LE  ( N  F,XT  <  NE  W_  S  T A  RT &NE  X  T-> = 0 ) ; 
\7  FREE_POINTER=NEXT; 

(  NEXT=MEM(FREE_POINTER); 


END; 


{ENTRY  ~  7 OF  LOOP  ) 
LOOP  ITERATES  Z  TIMES 


FREE LIST HEAD| 

FRFF.PGINTER] 

NEW-STAR  r  | 

NEXIl 

/ 

MEM  [ 

FREE  1  r 

I  FREE  2  I  I 

FREE  3 

NEW  [ 

FREE  4 

/*  FREE_POINTER  <  NEWSTART  <- NEXT  */ 

/*  OR  rREE_POINTER  <  NEW_START  &  NEXT=0  7 
LENGTH  =  MEM(FREE_POINTER+  l); 

IF  FREE.POINTER  +  LENGTIU NEW.  START  THEN 

/♦  MEMORY  TO  THE  LEFT  OF  NEW_START  IS  FREE  */ 

/*  MERGE  THE  2  PIECES  '/ 

MEM(FI<EE.P01NTER-I  1)-MEM(FREE_P01NTERh  1)pNEW_LENGT1I; 


FREE.LISr.HLADl 

FREE. POINTER  ||  NEW-STARFl 

nexTI 

■ 

1 

{ 

free  i  r 

I  FREE  2  | 

FREE  3 

FREE  4 

ELSE  _ _ _ 

.  DO;  7'  /  V  /  7~~7 

1  /*  MEMORY  TO  LEFT  OF  NEW.START  IS  IN  USE  */ 

|  /*  MALE  NEW  UNI'S  FOR  NEW  PIECE  */ 

:  M  E  M  ( N  E  W_S  TART ) = N  EX  T ;  ...  /  /  , 

I  MEM(NEVir_ST/VRT4 1)=NEW_LENGTH;  /  / 

!  M  EM(FRE  E-POINTER) = NEVLSTART; 
f  FKEEJ,OINTER=NEW_STACT; 

■  ™p:  .  _Z _ ✓ _ zLZ _ /  . 

END; 


figure  8-4c 


/*  step  2  •/ 

/»  AI.L  LINKS  IN  FREE  LIST  ARE  CORRECT  */ 

/*  FREE  J’OINTKR  POINTS  TO  •/ 

/»  PIECE  CONTAINING  {OR  =)  NEW  FREE  PIECE  */ 

/•  NEXT  POINTS  TO  •/ 

/•  FIRST  FREE  PIECE  TO  RIGHT  OF  FREE.POINTER,  */ 
/•  OR  TO  ZERO  ’/ 

/•  MERGE  ON  RIGHT  IF  NECESSARY  */ 

LENGTH  -  MEM(1’KEE_P0INTEI<4  1); 

IF  FREE_POINTER-t  LENGTH -NEXT  THEN 
DO; 

MEP(FP.EE_POINTER)-MEM(NEXT); 
MEM(FREE_POINTER4-l  )=  LENGTII  +  MEM(NEXT4  1); 

END; 


FREE LIST HEAD| 

FREE.POINIERl 

NEW.  SI API  1 

/ 

1  -.1 

1  FREE  2  |  1 

FREE  3 

MEMORY_SPACE_AVAILABLE =MEMORY_SPACEL  AVAILABLE4  NEW_LENGTH ; 

END; 

PROCEDURE  FREELPIECE  RETURNS 


figure  8-4c  (contd.) 


ENTRY  4  OF  PROCEDURE  FREE.  PIECE 
FREE_PIKCK:PROCFI>URKfNF:W_GTAKT.NKW_LENGTH); 

; DECLARKlNKW.START. NEW  LENGTH )FIXKD;  r”~  7  ' 

!dECIAKE(LENGTH,NEXT.FHEEJ’OINTKR)KIXED; 

[/•  STEP  1  */ 

'jY_  ALD  NEW  PIECE  TO  UST.  LEAVING  CORRECT  LINKS  ON  LEFT  SIDE  ♦/ 


IF  FREE.  UST_HEAI.»  NEW.  START  THEN  _  __  _ 

‘do.  ’  ’  7  ,7  ’  /  / 

-  /•  NEW  PIECE  IS  TO  ILFT  OF  FIRST  PIECE  IN  FREE  LIST  */ 
/*  ADD  NEW  PIECE  TO  BEGINNING  OF  FREE  LIST  */ 

I  .  •'  NFX7=FREK_L13T_HEAD; 

I  ME  M  { NEW. START )  =  N  EXT ; 

I  ME  W(NEW_START  +  1  j-NTW ’..LENGTH; 

-  FREE  .LIST.  IfSAD«-NEV7J5TART; 

,  FKEE_POINTER=NEW_START; 

Y  END;  ,  7  7  V  _j..-  7__7 _ 7__ 

ELSE 

DO; 

/•  NEW  PIECE  IS  BETWEEN  2  PIECES  IN  FREE  UST,  */ 

/’  OR  AFTER  LAST  PIECE  IN  FREE  LIST  */ 

/*  LOCATE  THESE  2  PIECES  OR  LAST  PIECE  */ 

FREE.  POINTER  =  FREE  .LIST.  HEAD; 
NEXT=MEM(FREE_POINTER); 


MEM 


FREEJJST.HEADl 

FREE  POINTERI 

NEXT  | 

NEW.START  | 

c 

I  FREE  1  |  I  FREE  2  I  I  NEW  I  |  FREE  3 


rDO  WHILE ( N EXTcNE W  START&NEXt-*=0);  '  7 
!.  FREE  POINTER-NEXT;  7 

NEXT»MEM(FP.EE_POINTER)';  7  .7 

,7  END:  7  7  /  7  .7  7  7 

~  "  ‘  ~(ENTRY  . 3  OF  LOOP  ) 

_ _ LOQP  ITERA  TPS  i  TIMES 


FREE.LIST.HEADl 

FREE.POINTER | 

NEW.START | 

NEXT] 

MEM  [ 

FREE  1  T~ 

FREE  2 

NEW  | 

FREE  3 

/*  FREE  POINTER  <  NEW. START  <  NEXT  */ 

/*  OR  FREEJ'OINTEP.  <  NEW. START  &  NEXT=0  •/ 

LENGTH  =  MEM(FREE_POINTER -F  l); 

IF  FREE_POINTER-t-LENGTH=NEW_START  THEN 

/*  MEMORY  TO  THE  LEFT  OF  NEW.START  IS  FREE  */ 

>  MERGE  THE  2  PIECES  */ 

|  MEM(FREE_POINTER-h  1  )=MEM(  FREEjOlNTERt  iKNEW.LEI^TH;  71 

ELSE 
DO; 

/*  MEMORY  TO  LEFT  OF  NEW_START  IS  IN  USE  */ 

/*  MALE  NEW  UNKS  FOR  NEW  PIECE  */ 

ME  M  ( NEW.STA.RT ) = N  EXT; 

MEM(NEW_START+1)=NEW_LENGTH; 

MEM(FREF,_POINTER)=  NEW.START;. 

FREE_P01NTER=NEW_START; 

END; 


FREE  .LIST .HEAD  | 

NEWSTART  ||  FREE  POINTER  | 

NEXT  | 

- - ^  ^ 

free!  r 

~\  FREE  2  T 

|FREE  3| 

FREE  4 

END, 


/*  STK)‘  2  •/ 

/»  AI.I,  I  .INKS  IN  FREE  LIST  ARE  CORRECT  */ 

/•  FRKEJ’OINTER  POINTS  TO  •/ 

/*  PIECE  CONTAINING  (OR  =)  NEW  FREE  PIECE  «/ 

/*  NEXT  POINTS  TO  V 

/*  FIRST  FREE  PIECE  TO  RIGHT  OF  FREE_POINTER.  */ 

/»  OR  TO  ZERO  V 

/*  MERGE  ON  RIGHT  IF  NECESSARY  •/ 

LENGTH -MEM(FREE_POINTER+l); 

IF  FREE_POINTER+LENGTfl=NEXT  THEN 

DO;  ‘  ~  v" 

MEM !  FREE  .POINTER)  =  MEM(N  EXT) ; 

•  WEM(FREE_POINTER+ 1 )  =  LENGTH +MEM(NEXT+1 ); 

END;  ...  _ :  •  _ ■  '  / 

MEMORYjSPACE_>.VAILABLE=MEMORY_SPACE_AVAILABLE+NEW_  LENGTH; 

END; 

PROCEDURE  FREEJP1ECE  RETURNS 


figure  8-4d  (contd.) 
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I D= ' YAR W DCD '  .ICO  70 

/*  TEST  OF  RECURSIVE  QUICKSORT  PROCEDURE  4/ 

T: PROCEDURE  OPT  IONS (MAIN)  ; 

DECLARE! ARRAY!  7), I  )FI:<EU  ; 

QUI  CKSC'RT:  P  70  C  SOUR  E  (  A  ,  L  ,  U  )  ; 

/*  SORTS  SECIZJT  \(L  : '  J )  */ 

DECLARE  (  U  *  >  ,  L  ,  u,  '<  )  I-  :  <E  3  ; 

S W A D :  PROCEDURE  !.<,Y  )  ; 

/*  S  V\Pi  VALUES  JP  A  (  X  )  ,  A  !  Y  )  -4/ 

DECL  ARE ( X , Y , T )  FIXED; 

T  =  A( X)  ; 

A! X)  = A ( Y  )  ; 

A  (  Y  )  =  T  ; 

E  id; 

PARTI T I EN  :  PROCEDURE ; 

/*  CHANCES  A ( ) ,  K  SUCH  THAT  */ 

/  ■■  A  (  L  :  K-  1  )  <  =  A  {  K  )  <=  A  (  K  +  1  :  U  )  */ 

DECL  AR  E ! N ) F I XED ; 

N=  L+  1  ; 

k  -  u ; 

/*NLEQK:  */ 

DO  WHILE (N<=K) ; 

Ic  A( N) <=A( L) THEN 
N=N+1; 

ELSE 

do; 

/’MOVER:  */ 

Dj  WHILE!  A ( K ) > A ( L )  )  ; 

K  -  K  - 1 ; 

END; 

IF  N<  K  THEN 
DO  ; 

CALL  S W A P ! N , K )  ; 

J = N  + 1  ; 
k  =  '<  - 1  ; 

END ; 

END; 

END ; 

CALL  SWAP! L  t  K )  ; 

Ell); 

IF  U<=L  THEN 
P.  E  T  J  R  N  ; 

IF  L  ~  L  +  1  THEN 
DO  ; 

IF  A  (  L  )  >  A  ( !J  )  7  H  E  N 
CALL  S  4 A P (  L , U )  ; 

return; 

END; 

CALL  PARTITION; 

C ALL  0  J  ICKSORT (  A,  L  ,  K- 1 )  ; 

CALL  UU  ICKS  J  R  T ( A , K  + 1 , U  J  ; 

figure  G-5 


It  END; 

K>  DO  1=1  TO  7; 

L  GET  L  1  S  7  (  AR-^A  Y  (  I  >  >  ; 

^  end; 

|J  CALL  vDUICKSJPK  ARRAY, 1  ,7)  ; 

fJ  END; 

I)  $  DA  TA 

I  OF  COMPILATION.  5  3  0  BYTES  OF  CODE  GENERATED. 

fcuTION  BEGINS. 


DR,  ON  LINE  46:  N G  MORE  INDIJT  DAT  A 


I  OF  EXECUTION  6  4  BYTES  OF  DATA  AREA  USED. 

5  STMTS  EXECUTED.  0  LINES  OUT  PUT • 

77  LINES  PRINTED 


ERRORS. 


figure  8-5(contd.) 


entry  1  of  procedure  QUICKSORT 


QUICKSORT  :  F  POC  E  D  !J  E  ( A  ,  L  ,  11 )  ; 

/*  SCPTS  SEGMENT  ( L  :  u )  v 
f  d  re  l>  !•  r  (  a  ( * )  l  ,  ti  ,k  )  :-'j  x  f  r Y  .x^ 

|  SWAP  :  L-FGCF DUKE  (X,  Y)  ;  ,x' 

/*xevsA ps  .values  cr' ;*  (X) , ,  a  ( y)  */y' 


/ 


X 


X 


x'  FNP;X  X 

'pAPTITTCN:  FFOCtDl’P  F  ; 

/*  CHANGES  A  ( )  ,  K  SUCH  THAI  */ 

//*  A.  (J.:K-1)  <=  A  ( K)  <=  A.  ( K  +  1  :  U )  */ 

»  •  x  X  x 

END;  x"  '•  X 


X 


XI 


IF  U<=L  THEN 


B  EX' l1  F  N  ; 


IF  u-n  1  THEN 
DC ; 


F  A  (Lb?  A  (D)  THEX 
CTyLL  s\\ 

FET'D  PU  ; 


CA1L  PARTITION  ; 


(entry  1  of 


procedure  PARTITION) 


■  a  ri  3 


CALL  COICKSOFT  (A,IfK- 1)  ; 

(entry  2  of  procedure  QUICKSORT) 

[3  P 

j 

A  Fl  2  3  4  7 

CALI.  QUICK  SCSI  (  A  ,  K  +  1  ,  l) )  ; 

(entry  5  of  procedure  QUICKSORT) 


E  N  D ; 


g  3 

a  ri~  ^  a— 

procedure  QUICKSORT  returns 


figure  0-6o 


entry  2  of  procedure  QUICKSORT 


QUICKSORT : PROCEDURE  (A  ,  L  ,  U ) ; 

/*  SORTS  S  FG  ME  NT  A(L:U)  */ 
D  E  Cl  AF  E  ( A )  ,  L  ,  U,  K")  FI  X  F  D,  ' 


SWAF  :  FFCCFDURE.<  a,  Y)  ; 
X  /+A\ iAPS  VALUES 


>■  a)  ,Xm  ♦a 


END ; 

PARTITION:  FFOCEDUF  E ; 

CHANGES  A(),XK  SUCH  TffAT  */ 
/*  A(>i'K-1)  <=  A  (K)  <?  A(K+1:U) 

*  ‘X  / 

/ND ;  x 


a 

4 

□ 

u 

A 

L  3 

l  A 

IF  U<=I  THEN 

[rHUrnTI 

IF  U  =  L  +  1  THEN 


CALL  PARTITION; 


(entry  2  of  procedure  PARTITION) 


CALI  QUICKSORT  (A, L,K-  1)  ; 

(entry  3  of  procedure  QUICKSORT) 
CALI  QUICKSORT  (A,K+  1  ,U)  ; 

(entry  4  of  procedure  QUICKSORT) 


END; 


procedure  QUICKSORT  returns 


figure  8-6b 


entry  3  of  procedure  QUICKSORT 


QUICK  SCOT  :  FPOCSniJPE  (A,  I  ,  U)  ; 

/*_  SCR1S  STGMEKT  ^(L:U)  */_ 
f  DF.CLP  F  Z  (A  ( *)  /IV'U/K)  11  X  E  r;;/-  " 

SWAP  :  EF£CFDURE,<Z#  V)  ; 

X  /Jy'SV, APS  VALUES  C A  ( X )  , x A  (  Y ) 

/  IHD;/ 

PAPTI7T C  N : FFOCEDUP E ; 

y*  CHA’IGFS  ^(),/K  SUCH  THAT  V 

/*  A(L:K-1)  <=  A  (K)  <=  A  ( K  +  1  :  U ) 

x  • 


*  •/' 

jekd ; 


—  r 


IF  U<-1  THEN 
BET  URN; 


procedure  QUICKSORT  returns 


figure  G-6c 


entry  4  of  jjfocedurc  QUICKSORT 


QUICKSORT  :  EPOCH  DO  BE  ( A  ,  L  ,  U )  ; 

/*  SCRTS  SEGMENT  A(L:U)  */ 
DEC! P?  E  (A  c+)  ;r;u,K)  FIX  15^ 
SW  A  E  :  F  F  GCE  D  U  R  E  X  ,  Y )  ; 
/*x£VAPS  VALUES  ‘ 


END;X 

PAHTITICN: FFOCEDUF  E  ; 

*  CHANGES  A(),.K  SUCH  TEAT  */ 

/*  A./K-l)  <='  A  (K)  <r'A(K+1:D)  */ 

•  -X 


/D ; 


Kj 

All 


L 

Uj 

it ^ 

/ 

IF  D<=I  THEN 
/BET URN ;  | 

IF  U=L  +  1  THEN 
DC; 

IF  A  (L) >A  (U) THEN 
CALL  SWAP  (L  ,  U) ; 


(entry  3  of  procedure 

SWAP) 

? 

\ 

L 

i 

E 

! 

i. 

A  Li 

2 

3 

BETUFN ; 


procedure  QUICKSORT  returns 


/END 

LX FAFTITICN  ; 


CALL 

CALL  QUICKSORT  (A<L,-K-1U 
CALL  QUICKSORT  (A,  K+l/)  ; 
END;x 


figure  8-6d 


entry  5  of  procedure  QUICKSORT 
QUICKSORT  :  FPOCrDOBE  (A,L,U)  ;  ' 


IF  D<=I  THEN 
Rj^CUEN;j 
IF  U  =  L  +  1  THEN 


(entry  3  of  procedure  PARTITION) 


A  1  1  2  _ 3  4  5  6~  7  i 

CALL  QUICKSORT  (A, L,K-1)  ; 

(entry  6  of  procedure  QUICKSORT) 

CALL  QUICKSORT  (A,K  +  1 ,0)  ; 

(entry  7  of  procedure  QUICKSORT) 

END; 


procedure  QUICKSORT  returns 


figure  0-6e 


entry  6  of  procedure  QUICKSORT 

QUICKSORT : FFOCEDOBE  (A,L  ,U)  ; 

/*  SCSI S  SFGMEJiT  A(L:U)  */ 

DECJL  P  F  l  ,  L  ,  0  ,  K'j  FIX  IZT 

SWAP  sFFpCEDURE/U,  Y)  ;  / 

^  /*/S* APS  VALUES  if'  A(X)-X(Y)  */ 


END; 

PARTITION:  FFOC"EDCRI;X 

'fc  CHANGES  ?.  ()  f  /K  SUCH  THAT  V 

K-1)  <ryP  (K)  9=  A(K+1:U)  */ 

/' 

:i(D ; 


Kl 

# 

All  2  3  ~4 

IF  U<=L  THEN 
FETT3FN : 

IF  D=L+1  THEN 
DO; 

IF  A  (L)  >A  (U)  THEN 
[CALL  SWAF(D<U); 

RETUFN ; 

procedure  QUICKSORT  returns 


P7  p5T 

CALL  PARTITION 
CAir  QUICKSORT  (A,L//£-1) 
CAT  I  GNIPKSORT  (A<K+1#D)^ 
"END; 


figure  8-6f 


entry  7  of  procedure  QUICKSORT 


QUICKSORT  :  EFOCZDORE (A ,L ,U)  ; 

/»  SC  RTS  S  FG  M  ENT _ A  ( IjJJ )  *  / 


DECREE  (A**)  ,L,U, 

SWAP  :  E  FJ2-CED  US  E.fX  f  Y)  ; 

X  /*/SSVAPS  ^VALUES  pr  A(;:),/A(Y)  */, 


•  # 

END;/ 

PARTITION:  FFOC'EDUF  E  ; 

-*  CHANGES  A  ()  , SUCH  THAT  */ 

/*  A(L:K-1)  <="A(K)  <7  '  A  ( K  +  1  :  U )  */ 

2™1 


IF  0<=1  THEN 
RETURN ; 


K 

r 

!  A  11  2  ~ 


procedure  QUICKSORT  returns 


figure  8-6g 
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